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Scope 



The present document specifies the stage three Protocol Description of the signalHng interworking between ISDN DSSl 
protocol and SIP based on the concatenation of ES 283 027 [1], ES 283 003 [5] with EN 300 899-1 [2]. The 
concatenation method describes only the SIP/ISDN parameter mapping without ISUP procedures. In addition direct 
inter- working not supported by this concatenation of these existing inter-working documents will be described. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 283 027: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Endorsement of the SIP-ISUP Interworking between the IP 
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[3GPP TS 29.163 (Release 7), modified]". 

[2] ETSI EN 300 899-1 (VI. 1.2): "Integrated Services Digital Network (ISDN);Signalling System 
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System No. One (DSSl);Part 1: Protocol specification [ITU-T Recommendation Q.699, 
modified]". 
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for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
(Release 7), modified]". 

[4] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[5] ETSI ES 283 003 (V2.5.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
[Release 7], modified]". 
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[7] ETSI TS 183 008: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services Terminating Identification 
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[8] ETSI TS 183 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN) PSTN/ISDN simulation services: Communication Diversion 
(CDIV); Protocol specification". 

[9] ETSI TS 183 005: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services: Conference (CONE); Protocol 
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[10] ETSI TS 183 010: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Signalling Control Protocol; Communication HOLD 
(HOLD) PSTN/ISDN simulation services; Protocol specification". 

[11] ETSI ETS 300 052-1: "Integrated Services Digital Network (ISDN); Multiple Subscriber Number 

(MSN) supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 

[12] ETSI ETS 300 055-1: "Integrated Services Digital Network (ISDN); Terminal Portability (TP) 
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[13] ETSI ETS 300 058-1: "Integrated Services Digital Network (ISDN); Call Waiting (CW) 

supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
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[ 1 8] ETSI ETS 300 097- 1 : "Integrated Services Digital Network (ISDN); Connected Line Identification 

Presentation (COLP) supplementary service; Digital Subscriber Signalling System No. One 
(DSSl) protocol; Part 1: Protocol specification". 

[19] ETSI ETS 300 098-1: "Integrated Services Digital Network (ISDN); Connected Line Identification 

Restriction (COLR) supplementary service; Digital Subscriber Signalling System No. One (DSSl) 
protocol; Part 1: Protocol specification". 

[20] ETSI ETS 300 130-1: "Integrated Services Digital Network (ISDN); Malicious Call Identification 

(MCID) supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 

[21] ETSI ETS 300 138-1: "Integrated Services Digital Network (ISDN); Closed User Group (CUG) 

supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 
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[22] ETSI ETS 300 141-1: "Integrated Services Digital Network (ISDN); Call Hold (HOLD) 

supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 

[23] ETSI ETS 300 185-1: "Integrated Services Digital Network (ISDN); Conference call, add-on 

(CONE) supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 

[24] ETSI ETS 300 188-1: "Integrated Services Digital Network (ISDN); Three-Party (3PTY) 

supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 

[25] ETSI EN 300 196-1 : "Integrated Services Digital Network (ISDN); Generic functional protocol for 

the support of supplementary services; Digital Subscriber Signalling System No. One (DSSl) 
protocol; Part 1: Protocol specification". 

[26] ETSI TS 183 006: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN) PSTN/ISDN simulation services Message Waiting Indication 
(MWl): Protocol specification". 

[27] ETSI EN 300 485 (Vl.2.3): "Integrated Services Digital Network (ISDN); Definition and usage of 

cause and location in Digital Subscriber Signalling System No. One (DSSl) and Signalling System 
No.7 ISDN User Part (ISUP) [ITU-T Recommendation Q.850 (1998), modified]". 

[28] ETSI TS 183 054: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Protocol specification Closed 
User Group (CUG)". 

[29] ETSI EN 300 403-1 : " Integrated Services Digital Network (ISDN); Digital Subscriber Signalling 

System No. One (DSSl) protocol; Signalling network layer for circuit-mode basic call control; 
Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]". 

[30] ITU-T Recommendation Q.951: "Digital Subscriber Signalling System No. 1 Stage 3 Description 

for Supplementary Services Using DSS 1". 

[31] ETSI TS 183 047: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN IMS Supplementary Services; Advice Of Charge 
(AOC)". 

[32] ETSI TS 183 028: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Common Basic Communication procedures; Protocol 
specification". 

[33] ETSI TS 129 163: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Interworking between the IP Multimedia (IM) Core 
Network (CN) subsystem and Circuit Switched (CS) networks (3GPP TS 29.163 version 7.7.0 
Release 7)". 

[34] ETSI EN 300 207-1: "Integrated Services Digital Network (ISDN); Diversion supplementary 

services; Digital Subscriber Signalling System No. One (DSSl); Part 1: Protocol specification". 

[35] ETSI EN 300 369-1 : "Integrated Services Digital Network (ISDN); Explicit Call Transfer (ECT) 

supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 

[36] ETSI TS 183 029: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services: Explicit Communication 
Transfer (ECT); Protocol specification". 

[37] ETSI EN 300 182-1: "Integrated Services Digital Network (ISDN); Advice of Charge (AOC) 

supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 
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[38] ETSI ETS 300 286-1: "Integrated Services Digital Network (ISDN); User-to-User Signalling 

(UUS) supplementary service; Digital Subscriber Signalling System No. One (DSSl) protocol; 
Part 1 : Protocol specification" . 

[39] ETSI EN 300 359-1: "Integrated Services Digital Network (ISDN); Completion of Calls to Busy 

Subscriber (CCBS) supplementary service; Digital Subscriber Signalling System No. One (DSSl) 
protocol; Part 1: Protocol specification". 

[40] ETSI EN 301 065-1 : "Integrated Services Digital Network (ISDN); Completion of Calls on No 

Reply (CCNR) supplementary service; Digital Subscriber Signalling System No. One (DSSl) 
protocol; Part 1: Protocol specification". 

[41] Void. 

[42] ETSI TS 183 043: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS-based PSTN/ISDN Emulation Stage 3 specification". 

[43] ETSI EN 301 798 (VI. 1.1): "Services and Protocols for Advanced Networks (SPAN); Anonymous 

Call Rejection (ACR) Supplementary Service; Service description". 

[44] IETF RFC 4575 (2006): "A Session Initiation Protocol (SIP) Event Package for Conference State". 

[45] IETF RFC 4244: "An Extension to the Session Initiation Protocol (SIP) for Request History 

Information" . 

[46] ETSI TS 183 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Malicious Communication 
Identification (MCID); Protocol Specification". 

[47] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[48] IETF RFC 4825: "The Extensible Markup Language (XML) Configuration Access Protocol 

(XCAP)". 

[49] ETSI TS 183 023: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Extensible Markup Language 
(XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating NGN 
PSTN/ISDN Simulation Services". 

[50] IETF RFC 4916: "Connected Identity in the Session Initiation Protocol (SIP)". 

[5 1 ] IETF RFC 4040: "RTP Payload Format for a 64 kbit/s Transparent Call" . 

[52] IETF RFC 3264: "An Offer/ Answer Model with Session Description Protocol (SDP)". 

[53] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[54] ITU-T Recommendation Q.93 1 : "ISDN user-network interface layer 3 specification for basic call 

control". 

[55] ITU-T Recommendation Q.939: "Typical DSS 1 service indicator codings for ISDN 

telecommunications services". 

[56] ITU-T Recommendation T.38: "Procedures for real-time Group 3 facsimile communication over 

IP networks". 

[57] EN 300 745-1 Vl.2.4 (1998): "Integrated Services Digital Network (ISDN) Message Waiting 

Indication (MWI) supplementary service Digital Subscriber Signalling System No. One (DSSl) 
protocol Part 1: Protocol specification". 

[58] ETSI TS 183 015: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN) NGN Signalling Control Protocol Communication Waiting 
(CW) PSTN/ISDN simulation services". 
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[59] ETSI TS 124 642: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Completion of Communications to Busy Subscriber 
(CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM)Core 
Network (CN) subsystem; Protocol Specification (3GPP TS 24.642 Release 8)". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] draft-johnston- sipping-cc-uui-02.txt. 

[i.2] ITU-T Recommendation Q.763: "Signalling System No. 7 - ISDN User Part formats and codes". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

en bloc receiving: procedure, used in call establishment of an incoming call, to enable the network to send called party 
number digits to the user in a single message 

NOTE: See EN 300 403-1 [29]. 

En bloc sending: procedure, used in call establishment of an outgoing call, to enable the user to send called party 
number digits to the network in a single message 

NOTE: See EN 300 403-1 [29]. 

Incoming AGCF/VGW: physical entity, which can be combined with a SIP UNI or NNl, terminates incoming calls 
using SIP protocol and originates outgoing calls using the DSSl protocol 

Outgoing AGCF/VGW: physical entity, which can be combined with an ISDN access device, terminates incoming 
calls using DSSl and originates outgoing calls using the SIP protocol 

overlap receiving: procedure, used in call establishment of an incoming call, to enable the network to send called party 
number digits to the user in successive messages, as and when they are made available from the remote network 

NOTE: See EN 300 403-1 [29]. 

Overlap sending: procedure, used in call establishment of an outgoing call, to enable the user to send called party 
number digits to the network in successive messages, as and when they are made available by the user 

NOTE: See EN 300 403-1 [29]. 

SIP Phone 3,1 KHz: native SIP endpoint that supports the G.71 1 codec. Such an endpoint may inter-work with an 
ISDN user in the IMS/PSTN for the 3,1 KHz bearer service due to both endpoints commonly supporting the G.71 1 
codec 

SIP Phone 7 KHz: native SIP endpoint that supports the G.722 codec. However, such an endpoint may not inter-work 
with an IISDN user in the IMS/PSTN for the 7 KHz bearer service as the VGW/AGCF/MGCF advertises the 
CLEARMODE codec (which enables a H.221 structure to be carried transparently - as described in G.725) rather than 
the G.722 codec 

NOTE: It is assumed that the CLEARMODE codec is not understood by the SIP endpoint. 

User: DSSl protocol entity at the user side of the user-network interface 

NOTE: See EN 300 403- 1 [29] . 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACK ACKnowledgement 

AGCF Access Gateway Control Function 

BC Bearer Capability information element 

BRI Basic Rate Interface 

CLIP Calling line Identification Presentation 

CLIR Calling line Identification Restriction 

COLP Connected Line Identification Presentation 

COLR Connected Line Identification Restriction 

CUG Closed User Group 

HOLD communication HOLD 

IFC Initial Filter Criteria 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Data Network 

IWF InterWorking Function 

MCID Malicious Communication Identification 

MRFC Multimedia Resource Function Controller 

NGN Next Generation Network 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

PES PSTN/ISDN Emulation Subsystem 

PRI Primary Rate Interface 

PSTN Public Switched Telephone Network 

S-CSCF Server-Call Session Control Function 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

SUB SUBaddressing 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

UA User Agent 

UE User Equipment 

URI Universal Resource Identifier 

UUS User User Service 

VGW Voice over IP GateWay 

XCAP PSTN/ISDN simulation services Extensible Markup Language (XML) Configuration Access 

Protocol 

XML extensible Markup Language 



General 



The present document describes guiding principles for implementing commonly deployed ISDN basic call and 
supplementary services using the IMS and IMS-based PES architecture. 

• ISDN terminals are connected to VGW or access gateways AGCF using BRI or PRI interfaces. The protocol 
running on the interfaces between these gateways and the PES is the session initiation protocol (SIP). 

The actual service logic resides in the Application Server and is outside the scope of standardization. This clause 
focuses on the interactions between the IWF. 
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Full support of supplementary services may be realized by exchanging service information between peer SIP signalling 
entities via SIP signalling. The DSSl information necessary to support each individual service is specified by the 
corresponding ETSI or ITU-T supplementary service specification; see table 4-1. For the management of several 
supplementary services (e.g. activation or deactivation of a service), two possibilities exist. The usage of the Ut 
interface allows the transport of the content of the DSSl Facility in PSTN XML instances as specified in the relevant 
simulation service to the XCAP server to manipulate the service. In addition, the usage of an empty INVITE to carry 
service code sequences is also applicable to manipulate the supplementary service. The applicability is a network 
provider option. The management of supplementary services in PES is out of scope of the present document. 

In case of the interworking for IMS simulation the mapping of PSTN XML Attachment parameters (Progresslndicator 
HighLayerCapability, LowLayerCapability, BearerCapability, Display; SendingComplete) and additional P-Early 
media header are a network provider option, in the IMS based PES they are mandatory. 

Table 4-1 : Supplementary Service References 



Supplementary Service 


ETSI Reference 


Calling Line Identification Presentation (CLIP) 


[16] 


Calling Line Identification Restriction (CLIR) 


[17] 


Connected Line Identification Presentation (COLP) 


[18] 


Connected Line Identification Restriction (COLR) 


[19] 


Terminal Portability (IP) 


[12] 


User-to-User Signalling (UUS) 


[38] 


Closed User Group (CUG) 


[21] 


Subaddressing (SUB) 


[14] 


Malicious Call Identification (MCID) 


[20] 


Conference Call (CONF) 


[23] 


Explicit Call Transfer (ECT) 


[35] 


Call Forwarding Busy (CFB) 


[34] 


Call Forwarding No Reply (CFNR) 


[34] 


Call Forwarding Unconditional (CPU) 


[34] 


Call Deflection (CD) 


[34] 


Call Hold (HOLD) 


[22] 


Call Waiting (CW) 


[13] 


Completion of Calls to Busy Subscriber (CCBS) 


[39] 


Three-Party (3PTY) 


[24] 


Completion of Calls on No Reply (CCNR) 


[40] 


Anonymous Communication Rejection (ACR) 


[43] 


Multiple Subscriber Numbering (MSN) 


[11] 


Direct Dialling In (DDI) 


[15] 


Advice of Charge (AOC) 


[37] 


Message Waiting Indication (MWI) 


[57] 



Interworking for IMS simulation / emulation services 



5.1 



Basic Call 



5.1 .1 Actions at the Outgoing AGCF/VGW 



5.1.1.1 



Sending of the Initial INVITE 



After initiating the normal incoming call establishment procedures, determining the end of address signalling and 
selecting to route the call to the IMS domain, the originating VGW/AGCF shall send the initial INVITE. As a network 
option, the originating VGW/AGCF may send INVITE requests without determining the end of address signalling. 

The end of address signalling shall be determined by the earlier of the following criteria: 

a) by receipt of a "#" character as a sending complete indication or Sending complete information element; 

b) optional by receipt of the maximum number of digits used in the national numbering plan; or 
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c) optional by analysis of the called party number to indicate that a sufficient number of digits has been received 
to route the call to the called party. 



Table 5.1.1.1-1: Mapping of sending complete info element 


SETUP/INFO ^ 


INVITE/XXX -^ 


Information element 


PSTN XML attachment 


sending complete 


sendingCompletelndication 



5.1.1.1.1 



En-bloc sending according to EN 300 403-1 , clause 5.1 .1 



If en-bloc sending is used, the SETUP message contains the complete called number information. The called party 
number information is included in the Called party number information element possibly completed by the Called party 
subaddress information element. 

The network shall send a CALL PROCEEDING message to the user. This acknowledges the SETUP message and 
indicates that the call is being processed and that no further address information is expected. 

The AGCF/VGW can contain a configurable digit map which is used to analyse the Called party information element 
contents received in Called party number information element. Among other purposes, this digit map can be used to 
identify the required number of digits to be entered for a particular digit sequence for a particular service. The 
procedures for digit maps are described within TS 183 043 [42], clause 7.3.1.3.1.1. 

Even in the absence of a digit map, it is appropriate for the AGCF/VGW to collect dialled digits. The AGCFVGW shall 
contain a configurable parameter indicating the minimum number of digits expected in the sequence of Called party 
number information elements before a Request-URI is constructed and an INVITE request sent. The minimum number 
could be zero. 

If this option does not apply, the VGW has to assume overlap sending. 

If en-bloc sending is used, the SETUP message may contain the sending complete indication (IE the Sending complete 
information element) (see EN 300 403-1 [29]). 

It is mandatory for the network to recognize the Sending complete information element. 



5.1.1.1.2 



Bearer capability mapping 



The "information transfer capability" code point of the bearer capability information element in the SETUP message 
shall be mapped to the SDP in SIP according to table 5.1.1.1.2-1. 

Table 5.1 .1 .1 .2-1 : Coding of the BC received 



SETUP -^ 


INVITE^ 


Bearer capability information element 


Coding of SDP media description lines from BC/HLC to SIP 


Information transfer capability 




Speech 


see table 5.1.1.1.4-2 


3,1 kHz audio 


see table 5.1.1.1.4-2 


Unrestricted digital inf. W/tone/ann 


see table 5.1.1.1.4-2 


unrestricted digital information 


see table 5.1.1.1.4-2 



In addition, the whole bearer capability information element, as received in the SETUP message, shall be mapped to the 
PSTN XML bearer capability body in SIP, according to table 5.1.1.1.2-2. 

If two EC's are received then: 

• the BC 2 shall be mapped to the first SDP entry of the SIP INIVITE; and 

• the BC 1 shall be mapped to the second SDP entry of the SIP INVITE; and 

• the AGCF/VGW shall store the BC values. 

This is needed for the Fall back mechanism as described within clause 5.1.1.2.2. 
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Table 5.1 .1 .1 .2-2: Mapping of Bearer capability to PSTN XIUIL BearerCapability 



SETUPS 


INVITE^ 


Content 


PSTN XML attachment BearerCapability 


One BC received: 
BC 


BearerCapability mapped from the BC 
Information element (see note 2) 


Two BC received (see note 1): 

BC 1 {speech or 3, 1 kHz audio) 

BC 2 (unrestricted digital information with 

tones and announcements) 


BearerCapability 1 mapped from the BC 1 
Information element (see note 2) 
BearerCapability 2 mapped from the BC 2 
Information element (see note 2) 


NOTE 1 : BC 1 is the bearer capability information element received in first position in the SETUP 
message, BC 2 in the second position. Bearer capability information elements shall be 
received in ascending order of priority as described in 5.11.1.1/0.931 [54]. 

NOTE 2: Octet 1 (information element identifier) and 2 (length) of the bearer capability 
information element are not included. 



5.1.1.1.3 



Mapping of Progress indicator/High Layer Compatibility/Low Layer Compatibility 



A progress indicator IE, high layer compatibility IE, or low layer compatibility IE, if received in a SETUP message, 
shall be mapped to the PSTN XML attachment in SIP, according to table 5.1.1.1.3-1. 

Table 5.1 .1 .1 .3-1 : Mapping of the Progress indicator/High Layer 
Compatibility/Low Layer Compatibility IE 



SETUPS 


INVITE^ 


Content 


PSTN XML Attachment 


Progress indicator 


Progresslndicator 


High layer compatibility 


HighLayerCapability 


Low layer compatibility 


LowLayerCapability 



Table 5.1 .1 .1 .3-2: Mapping of the High Layer Compatibility 



SETUPS 


INVITE -^ 


Content 


PSTN XML 


One HLC received: 
HLC 


HighLayerCapability HLC 


Two HLC received (see note 1): 
HLC1 
HLC 2 


HighLayerCapability (content of HLC 1) (see note 2) 
HighLayerCapability (content of HLC 2) (see note 2) 


NOTE 1 : HLC 1 Is the high layer compatibility information element received in first position in the 
SETUP message, HLC 2 in second position. High layer compatibility information 
elements shall be received in ascending order of priority as described in 
5.12.1.1/0.931 [54]. 

NOTE 2 Octets 1 (information element identifier) and 2 (length) of the high layer compatibility 
information element are not included. 
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Table 5.1.1.1.3-3: Coding of the progress indicator information element 



SETUPS 


INVITE^ 


Progress indicator information 
element 


PSTN XML attachment 


No. Value of PI (see note 1) 


PSTN XML with Progresslndicator No (Value of PI) 
PSTN XML with Progresslndicator. No. 6 (see note 2) 




PSTN XML with Progresslndicator. No. 6 (see note 2) 


NOTE 1 : Except value 

No. 2 - Indicates that the destination user is not ISDN; 

No. 8, "in-band information or an appropriate pattern is now available". 
NOTE 2: The ISDN access indicator - "originating access ISDN" is transported in the IMS 

as PSTN XML Progresslndicator No. 6 see annex E. 



The calling and called party subaddress information shall be mapped to SIP as described in clause 5.2.8. 



5.1.1.1.4 



Request URI/To header field 



Table 5.1.1.1.4-1: IVIapping DSS1 Called Party Number to 
SIP Request-URI and To header field 



SETUP 


INVITE 


Called Party Number 


Request-URI and To header field 


Type of number 




Unknown 




Dialled strings 

E. 164 Number format 
LN (local number) 


Option a) 

sip: dialled digits@homehostportion (see note) 

Option b) 

sip: dialled digits; phone-context=<xxxxxx >@homehostportion; user=xxxx 

(see note) 

Option c) 

sip: dialled digits @homehostportJon; user=xxxx (see note) 


E. 164 Number format 
Prefix+NDC+SN 
(national number) 


E. 164 Number format 
Prefix + CC+NDC+SN 
(international number) 


Subscriber number 


Option a) 
sip:subscribernumber@homehostportion (see note) 

Option b) 

sip: subscribernumber; phone-context=<xxxxxx>@homehostportion; 

user=xxxx (see note) 

option c) 

tel: subscribernumber;phone-context= <xxxxxx> (see note) 


Network specific number 


Option a) 

sip: network-specific-number@homehostportion (see note) 

Option b) 

sip: network-specific-number;phone- 

context=<xxxxxx>@homehostportion;user=xxxx (see note) 


Abbreviated number 


Option a) 

sip: dialled digits@homehostportion (see note) 

Option b) 

sip: dialled digits; phone-context=<xxxxxxx>@homehostportion; user=xxxx 

(see note) 
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SETUP 


INVITE 


Called Party Number 


Request-URI and To header field 


Type of number 




National number 


Option a) 

sip: national number@homehostportion (see note) 

Option b) 

sip: national number; phone-context=< xxxxxx>@homehostportion; user=xxxx 

(see note) 

Option c) 

tel: national number;phone-context=<xxxxxx> (see note) 


International number 


Option a) 

sip: "+" dialled digits@homehostportion; user= phone (see note) 

Option b) 

tel: "+" dialled digits (see note) 


NOTE: The combination of digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 
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Table 5.1.1.1.4-2: Coding of SDP media description lines from BC/HLC to SIP 



BC IE (normative) 


HLC IE in 
(Optional) 


m= line 


b= line 


a= line 


Information 
Transport Capability 


User Information 

Layer 1 Protocol 

Indicator 


High Layer 

Characteristics 

Identification 


<media> 


<transport> 


<fmt-list> 


<modifier 

>: 
<bandwid 
th-value> 


rtpmap:<dynamic-PT> 

<encoding name>/<clock 

rate>/encoding parameters> 


"Speecli" 


"G.711 M-law" 


Ignore 


Audio 


RTP/AVP 


(and possibly 
8) (see note 1) 


AS:64 


rtpmapiO PCI\/IU/8000 
(and possibly rtpmap:8 
PCMA/8000) 
(see note 1) 


"Speecli" 


"G.711 M-law" 


Ignore 


Audio 


RTP/AVP 


Dynamic PT 

(and possibly a 

second Dynamic 

PT) 

(see note 1) 


AS:64 


rtpmap:<dynamic-PT> 

PCMU/8000 

(and possibly rtpmap:<dynamic- 

PT> PCMA/8000) (see note 1 ) 


"Speech" 


"G.71 1 A-law" 


Ignore 


Audio 


RTP/AVP 


8 


AS:64 


rtpmap:8 PCMA/8000 


"Speecli" 


"G.71 1 A-law" 


Ignore 


Audio 


RTP/AVP 


Dynamic PT 


AS:64 


rtpmap:<dynamic-PT> 
PCMA/8000 


"3,1 kHz audio" 


"G.711 M-law" 


Ignore 


audio 


RTP/AVP 


(and possibly 

8) 

(see note 1) 


AS:64 


rtpmap:0 PCMU/8000 
(and possibly rtpmap:8 
PCMA/8000) (see note 1) 


"3,1 kHz audio" 


"G.71 1 A-law" 


Ignore 


audio 


RTP/AVP 


8 


AS;64 


rtpmap:8 PCMA/8000 


"3,1 kHz audio" 


"G.71 1 A-law" 


"Facsimile Group 
2/3" 


image 


UdptI 


t38 [56] 


AS:64 


Based on ITU-T Rec. T.38 [56] 


"3,1 kHz audio" 


"G.71 1 A-law" 


"Facsimile Group 
2/3" 


image 


TcptI 


t38 [56] 


AS:64 


Based on ITU-T Rec. T.38 [56] 
isup_usi mapped from BC IE (see 
note 4) 


"3,1 kHz audio" 


"G.711 M-law" 


"Facsimile Group 
2/3" 


image 


UdptI 


t38 [56] 


AS:64 


Based on ITU-T Rec. T.38 [56] 
isup_usi mapped from BC IE (see 
note 4) 


"3,1 kHz audio" 


"G.711 M-law" 


"Facsimile Group 
2/3" 


image 


TcptI 


138 [56] 


AS:64 


Based on ITU-T Rec. T.38 [56] 


"Unrestricted digital 
inf. W/tone/ann." 
(see notes 4 and 5) 


N/A 


Ignore 


audio 


RTP/AVP 


Dynamic PT 


AS:64 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 


"Unrestricted digital 
information" 


N/A 


Ignore 


audio 


RTP/AVP 


Dynamic PT 


AS:64 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 


NOTE 1 : Both PCMA and PCIVIU could be required. 

NOTE 2: CLEARMODE is specified in RFC 4040 [51 ]. 

NOTE 3: The mapping of the "Information Transport Capability" to the proper codec is explained in annex B. 

NOTE 4: In case of receiving two BC elements and each shall be mapped to an m line. The Fallback possibility is described within clause 5.1 .1 .2.2. 

NOTE 5: After the CLEARMODE codec, an additional speech codec G.71 1 should be offered in the same m-line. 
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5.1.1.2 



Receipt of a Provisional Response 18x 



The SDP answer is described in annex B. 



5.1.1.2.1 



180 Ringing response 



Depending on the following three cases, the AGCFA'^GW shall send an ALERTING message across the user-network 
interface to the calling user, as described in table 5.1.1.2.1-1. 

• the reception of the first 180 Ringing response without a P-Early-Media header (authorizing early media); or 



AGCFA^GW 



ALERTING 



Ring tone 



180 Ringing 



Figure 5.1.1.2.1-1: Sending of ALERTING (Receipt of first 180 Ringing 
without authorization of early media) 

NOTE 1: The ringing tone is sent only for voice services. 

• the reception of the first 180 Ringing with a P-Early-Media header (authorizing early media); or 

AGCFA^GW 



ALERTING with PI#8 


180 Ringing 
P-Early-Media 








Ring tone 







Figure 5.1.1.2.1-2: Sending of ALERTING (Receipt of first 180 Ringing 
that includes authorization of early media) 

NOTE 2: Based on local knowledge that the call is transited to a PSTN network, the AGCF/VGW can make a 

decision not to generate the awaiting answer indication when receiving the 180 Ringing message without 
a P-Early-Media header. 

• once all the following sub-conditions have been met: 

1) the reception of the first 183 Session Progress that includes a P-Early-Media header authorizing early 
media; 

2) the SDP offer/answer procedures are completed; and 

3) SDP preconditions are not used, or applicable SDP preconditions have been met. 
The support of the reception of the P-Early-Media header is mandatory for the AGCF/VGW. 
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If the AGCF/VGW receives a 18x response with a P-Early-media header that changes the authorization of early media: 

if the header authorizes early media and if the AGCF/VGW is sending the awaiting answer indication, the 
AGCF/VGW shall terminate the sending of the awaiting answer indication; and 

if the header removes authorization of early media and if the AGCF/VGW has received the 180 Ringing 
response, the AGCF/VGW shall initiate the sending of the awaiting answer indication. 

In the event of the P-Early-Media header not being present in the ISx message and a media flow being received, such a 
media flow would ideally not be authorized. However, under these circumstances, a VGW may, as a network option, 
forward the received media flow and send an ALERTING, CALL PROCEEDING or PROGRESS message with a 
Progress Indicator set to 8 (In-band information or appropriate pattern now available). 

NOTE 3: This behaviour enables managing the case when the remote entity generating early media does not 
support the P-Early-Media header. 

Table 5.1.1.2.1-1 : Message sent to the DSS 1 upon receipt of first 180 



<-Message sent to the DSS 1 
ALERTING 


<r- 180 Ringing 


Progress indicator 
information element 




No. 1 (see note 1) 

{Call is not end-to-end ISDN: further progress Information 

may be available in-band) 


No PSTN XML Progresslndicator 


No. 8 (see note 1) 

{In-band information or appropriate pattern 

now available) 


P-Earl-Media header (see note 3) 


No. Value of PI (see note 2) 


PSTN XML with Progress indicator No (Value of PI) and 
PSTN XML Progresslndicator No. 7 (see note 2) 


No. Value of PI 


PSTN XML with Progress indicator No (Value of PI) 




PSTN XML with Progress indicator No 7 (see note 2) 


NOTE 1 : The progress indicator is only sent if the BC received in the SETUP message is coded "speech", "3,1 kHz 

audio" or "unrestricted digital information with tones and announcements". 
NOTE 2: The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 

Progresslndicator No. 7 and is not sent to the access see annex E. 
NOTE 3: The PSTN XML Progresslndicator No. 8 may also be present, in which case only one Pl=8 is signalled to 

DSS1. 
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Table 5.1.1.2.1-2: Message sent to the DSS 1 upon receipt of subsequent 180 



^-Message sent to the DSS 1 
PROGRESS (note 1) 


<- 180 Ringing 


Progress indicator 
information element 




No. 1 (see note 4) 

(Call is not end-to-end ISDN: further progress Information 

may be available in-band) 


No PSTN XML Progresslndicator 


No. 8 

[In-band information or appropriate pattern 

now available) 


P-Earl-Media header (see note 6) 


No. Value of PI (see note 3) 

No. 4 (see note 5) 

[Call has returned to the ISDN) 


PSTN XML with Progress indicator No (Value of PI) and 
PSTN XML Progresslndicator No. 7 (see note 3) 


No. Value of PI (see note 7) 


PSTN XML with Progress indicator No (Value of PI) 


No. 4 (see note 5) 

[Call has returned to the ISDN) 


PSTN XML with Progress indicator No 7 (see note 3) 


NOTE 1 : CALL PROCEEDING is sent if not sent previously - else PROGRESS. 

NOTE 2: The progress indicator is only sent if the BC received in the SETUP message is coded "speech", "3,1 kHz 
audio" or "unrestricted digital information with tones and announcements". 

NOTE 3: The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 
Progresslndicator No. 7 and is not sent to the access see annex E. 

NOTE 4: This value is sent if Pl=4 was signalled immediately previously. 

NOTE 5: This value is sent if Pl=1 or Pl=2 was signalled immediately previously. 

NOTE 6: The PSTN XML Progresslndicator No. 8 may also be present, in which case only one Pl=8 is signalled to 
DSS1. 

NOTE 7: Values 1 ("call is not end-end ISDN") or 2 ("destination address is not ISDN") are sent if Value 4 ("Call has 
returned to the ISDN") has been sent since value 1 or 2 was previously sent or if no value 1 or 2 was 
previously sent. Value 4 ("Call has returned to the ISDN") is sent if value 1 ("call is not end-end ISDN") or 2 
("destination address is not ISDN") was sent previously and no value 4 has been signalled since. 



5.1.1.2.1.1 



Progress indicator 



If the Progress indicator information elements are present in the PSTN XML attachment of the SIP Provisional 
Response, they shall be transferred in the DSSl message sent to the calling user. 

In addition, progress indicator information elements are created by the originating AGCF/VGW according to 
tables 5.1.1.2.1-1 and 5.1.1.2.1-2. 

In case of fallback to an alternative bearer capability or high layer compatibility, according to EN 300 403-1 [29], 
clauses 5.11 and 5.12, a progress indicator No. 5 (interworking has occurred and has resulted in a telecommunication 
service change) shall be sent by the ACGF/VGW, as described in tables 5.1.1.3-1 and 5.1.1.3-2. 

Every message sent to the DSSl user (ALERTING, CALL PROCEEDING or PROGRESS) may contain two progress 
indicator information elements. When more than two progress indicator information elements are to be sent, the 
subsequent progress indicator information elements are sent in a PROGRESS message. 



5.1.1.2.1.2 



High layer compatibility 



If a high layer compatibility information element is present in the PSTN XML attachment of the SIP Provisional 
Response, the mapping to the HLC IE is described in table 5.1.1.2.1.2-1. 

Table 5.1.1.2.1.2-1: Sending of HLC fallback information 



^-Message sent to DSS 1 


<-180 


Content 


PSTN XML attachment 


HLC 


HighLayerCompatibility 


NOTE: The HighLayerCompatibility information in the PSTN XML attachment of the SIP body shall be mapped, if 
present, to the HLC IE (EN 300 403-1 [29], clause 4.5.17, table 4-23/Q.931 [54]). 
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5.1 .1 .2.1 .3 Handling of fallback information 

a) Bearer capability selection procedure 

According to EN 300 403-1 [29], clause 5.11, the mapping shall be done as described in table 5.1.1.2.1.3-1. 

Table 5.1 .1 .2.1 .3-1 : Sending of BC fallback information 



<-Message sent to DSS 1 
ALERTING 


^180 




PSTN XML attachment 


See note 1 


BearerCapability {speech or 3,1 kHz audio) (see note 2) 


NOTE 1 : The AGCF/VGW stores the PSTN XML Bearer Capability element for this dialog. 
NOTE 2: The received BearerCapability information should contain a Speech or 3,1 kHz BC. 



If a high layer compatibility information element is present in the PSTN XML attachment of the 180 Ringing, and if no 
progress indicator No. 1 (call is not end-to-end ISDN) or No. 2 (destination address is non-ISDN) has to be sent, 
table 5.1.1.2.1.3-1 is applicable. 

b) High layer compatibility selection procedure 

According to EN 300 403-1 [29], clause 5.12, the mapping shall be done as described in table 5.1.1.2.1.3-2. 

Table 5.1.1.2.1.3-2: Sending of HLC fallback information 



<-Message sent to DSS 1 


^180 


ALERTING 


PSTN XML attachment 


See note 


HighLayerCapability 


NOTE: The AGCF/GW stores the received PSTN XML attachment for this dialog. 



c) SDP selection procedure 

When a SDP answer was received indicating no support of the 7 kHz call setup (CLEARMODE codec not the first 
codec in the m line), the fallback shall not apply as the call may not yet have reached its final destination (e.g. CFNR 
occurring). 

Table 5.1 .1 .2.1 .3-3: No CLEARMODE support in the SDP 



<-Message sent to DSS 1 


^180 


ALERTING 


SDP 




CLEARMODE not the first codec on the codec list 



5.1 .1 .2.2 Receipt of the 1 83 (Session Progress) response 

Once all the following sub -conditions have been met: 

• if the AGCFA'GW has received the first 183 Session Progress that includes a P-Early-Media header 
(indicating authorization of early media); and 

• SDP preconditions are not used or applicable SDP preconditions have been met. 

The AGCF/VGW shall send a CALL PROCEEDING or PROGRESS message according to table 5.1.1.2.2.3-2 to the 
calling user, as described in table 5.1.1.2.2.3-2. 
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0-AGCFA^GW 



CALL PROC/PROGRESS 

in-hand infnrmaitinn available 


183 Progress 
P-Early-Media 






4 


appropriate announcement 



Figure 5.1.1.2.2-1 : Sending of Call Proceeding (Receipt of first 183 that includes 

authorization of early media) 

In the event of the P-Early-Media header not being present in the 18x message and a media flow being received, such a 
media flow would ideally not be authorized. However, under these circumstances, a VGW may, as a network option, 
forward the received media flow and send an ALERTING, CALL PROCEEDING or PROGRESS message with a 
Progress Indicator set to 8 (In-band information or appropriate pattern now available). 

NOTE: This behaviour enables managing the case when the remote entity generating early media does not 
support the P-Early-Media header. 



5.1.1.2.2.1 



Progress indicator 



Table 5.1.1 .2.2.1-1: Message sent to the DSS 1 interface upon receipt of 183 

(Session Progress) response 



<-Message sent to the DSS 1 


<- 183 Session Progress 


CALL PROCEEDING when not been sent 
before (see note 1) 


Progress Indicator IE: 
Progress description No. 8 (see note 3) 
(In-band information or appropriate 
pattern now available) 


P-Earl-Media header (see 
note 7) 


Progress Indicator IE: 

Progress description No. Value of PI 

(see note 5) 


PSTN XML with Progress 
indicator (Value of PI) and 
Progresslndicator No. 7 
(see note 5) 


PSTN XML with Progress indicator 
(Value of PI) (see note 8) 


Progress Indicator IE: 
Progress description No. 
Value of PI 




PSTN XML 

Progresslndicator No. 7 
(see note 5) 
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<-Message sent to the DSS 1 


<- 183 Session Progress 


PROGRESS if a progress indicator 
information element is contained in 183 
(see note 2) 


Progress Indicator IE: 
Progress description No. 8 (see note 3) 
(In-band information or appropriate 
pattern now available) 


P-Earl-Media header (see 
note 7) 


Progress Indicator IE: 

Progress description No. Value of PI 

(see note 5) 

No. 4 (see note 6) 

(Call has returned to the ISDN) 


PSTN XML with Progress 
indicator (Value of PI) and 
PSTN XML 

Progresslndicator No. 7 
(see note 5) 


PSTN XML with Progress indicator 
(Value of PI) (see note 8) 


Progress Indicator IE: 
Progress description No. 
Value of PI 


No. 4 (see note 6) 

{Call has returned to the ISDN) 


PSTN XML 

Progresslndicator No. 7 
(see note 5) 


NOTE 1 : The receipt from tlie networl< of an 183 is interpreted by the network as a sending complete indication, in 

the case where the network couldn't determine it before. 
NOTE 2: The sending of a progress indicator information element is described above. 
NOTE 3: The progress indicator is only sent if the BC received in the SETUP message is coded speech, 3, 1 kHz 

audio. 
NOTE 4: If a PSTN XML attachment HLC is received, it shall be mapped to the HLC IE. 
NOTE 5: The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 

Progresslndicator No.7 and is not sent to the access. 
NOTE 6: This value is sent if Pl=1 or Pl=2 was signalled immediately previously. 
NOTE 7: The PSTN XML Progresslndicator No. 8 may also be present, in which case only one Pl=8 is signalled to 

DSS1. 
NOTE 8: Values 1 ("call is not end-end ISDN") or 2 ("destination address is not ISDN") are sent if Value 4 ("Call has 

returned to the ISDN") has been sent since value 1 or 2 was previously sent or if no value 1 or 2 was 

previously sent. Value 4 ("Call has returned to the ISDN") is sent if value 1 ("call is not end-end ISDN") or 

2 ("destination address is not ISDN") was sent previously and no value 4 has been signalled since. 



If more than two progress indicator information elements are to be sent, the subsequent progress indicator information 
elements shall be sent in a PROGRESS message. 



5.1.1.2.2.2 



High layer compatibility 



If a high layer compatibility information element is present in the PSTN XML attachment of the 183 Session Progress, 
see handling of fallback information in clause 5.1.1.2.2.3. 

5.1 .1 .2.2.3 Handling of fallback information 

a) Bearer capability selection procedure 

According to EN 300 403-1 [29], clause 5.11, the mapping shall be done as described in table 5.1.1.2.2.3-1. 

Table 5.1 .1 .2.2.3-1 : Sending of BC fallback information 



<-Message sent to DSS 1 


<-183 Session Progress 


CALL PROCEEDING or PROGRESS 


PSTN XML attachment 


See note 1 


BearerCapability (speech or 3,1 kHz audio) 
(see note 2) 






NOTE 1 : The AGCF/VGW stores the received PSTN XML for this dialog. 

NOTE 2: The received BearerCapability information should contain a Speech or 3,1 kHz BC. 



If a high layer compatibility information element is present in the PSTN XML attachment of the 183 Session Progress, 
and if no progress indicator No. 1 (call is not end-to-end ISDN) or No. 2 (destination address is non-ISDN) has to be 
sent, table 5.1.1.2.1.3-1 is applicable. 
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b) High layer compatibility selection procedure 

According to EN 300 403-1 [29], clause 5.12, the mapping shall be done as described in table 5.1.1.2.1.3-2. 

Table 5.1.1.2.2.3-2: Sending of HLC fallback information 



^-Message sent to DSS 1 


<-183 Session Progress 


<- CALL PROCEEDING or PROGRESS 


PSTN XML attachment 


See note 


HighLayerCapability 
Progress indicator No. 5 


NOTE: The AGCF/VGW stores the received PSTN XML for this dialog. 



c) SDR selection procedure 

When a SDP answer was received indicating no support of the 7 kHz call setup (no CLEARMODE codec in the 
m line), the fallback shall not apply as the call may not yet have reached its final destination (e.g. application of an 
indication). 

Table 5.1.1.2.2.3-3: Sending of fallback information no support in the SDP 



^-Message sent to DSS 1 


<- 183 Session Progress 


<r- CALL PROCEEDING or PROGRESS 


SDP 


Progress Indicator No. 8 (see note) 


CLEARMODE not the first codec on the codec list 


NOTE: The AGCF/VGW may send the Progress Indicator No.8 also in a PROGRESS message to the user. 



5.1.1.3 



Receipt of the 200 OK INVITE 



Upon receipt of a 200 OK INVITE and the 200 OK INVITE does not contain the from-change tag in the Supported 
header, the AGCF/VGW shall send a CONNECT message across the user-network interface to the calling user. If the 
from-change tag in the Supported header is contained in the 200 OK INVITE, the applicable procedures are described 
in clause 5.2.2.2. 

The SDP answer is described in annex B. 

The CONNECT message is coded as follows. 

Table 5.1.1.3-1 : Sending criteria of the progress indicator information elements 

created by the VGW/AGCF 



^ CONNECT 


^ 200 OK 


Progress Indicator 
Information element 




Progress description No. 1 (see note 2) 

(Call is not end-to-end ISDN: further progress Information 

may be available in-band) 


No PSTN XML Progresslndicator 


Progress description No. Value of PI 
Progress description No. 4 (see note 3) 
[Call has returned to the ISDN) 


PSTN XML with Progress indicator No (Value of PI) and 
PSTN XML Progresslndicator No. 7 (see note 1) 


Progress description No. Value of PI (see note 4) 


PSTN XML with Progress indicator No (Value of PI) 


Progress description No. 4 (see note 3) 
{Call has returned to the ISDN] 


PSTN XML Progresslndicator No. 7 (see note 1) 


NOTE: 1 The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 
Progresslndicator No. 7 and is not sent to the access see annex E. 

NOTE 2: This value is sent if Pl=1 not previously sent or Pl=4 was signalled immediately previously. 

NOTE 3: This value is sent if Pl=1 or Pl=2 was signalled immediately previously. 

NOTE 4: Values 1 ("call is not end-end ISDN") or 2 ("destination address is not ISDN") are sent if Value 4 ("Call has 
returned to the ISDN") has been sent since value 1 or 2 was previously sent or if no value 1 or 2 was 
previously sent. Value 4 ("Call has returned to the ISDN") is sent if value 1 ("call is not end-end ISDN") or 2 
("destination address is not ISDN") was sent previously and no value 4 has been signalled since. 



NOTE: The PES AS shall assure that the correct PI and their combination is provided to the AGCF/VGW. 
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The CONNECT message sent to the access may contain two progress indicator information elements. 

When more than two progress indicator information elements are to be sent, the subsequent progress indicator 
information elements shall be sent in a PROGRESS message. 

High layer compatibility 

If a high layer compatibility information element is present in the PSTN XML attachment of the 200 OK INVITE, see 
handling of fallback information at the end of this clause. 

Low layer compatibility 

The low layer compatibility possibly present in the PSTN XML attachment of the 200 OK INVITE is passed on 
unchanged. 

History-Info header 

See clause 5.2. 

User-user 

See clause 5.2. 

P-Asserted-Identity 

See clause 5.2. 

Connected subaddress 

See clause 5.2. 

Handling of fallback information 

According to EN 300 403-1 [29], clause 5.11, the mapping shall be done as described in table 5.1.1.3-2. 

Table 5.1.1.3-2: Sending of BC fallback information 



^CONNECT (see note 1) 


^200 OK INVITE 




PSTN XML attachment 


SDP m line 


BC derived from received BearerCapability 
(Unrestricted digital information with tones 
and announcements) 


BearerCapability (unrestricted digital 
information with tones and 
announcements) (see note 2) 


The first stated codec has to be 
consistent with the PSTN XML 
BearerCapability 


BC derived from received BearerCapability 
(speech or 3,1 kHz audio) 
Progress Indicator No. 5 


BearerCapability (speech or 3,1 kHz 
audio) (see note 2) 


The first stated codec has to be 
consistent with the PSTN XML 
BearerCapability 


B C (speech or 3, 1 kHz audio) 
Progress Indicator No. 5 


No PSTN XIVIL attachment 


The SDP answer has 
precedence (see note 3) 


NOTE 1 : If fallback allowed was indicated in the SETUP message, and fallback occurs at the destination, or fallback 

does not occur, the AGCF/VGW shall include in the CONNECT message the BC IE of the resultant bearer 

service. 
NOTE 2: If the SDP answer is not consistent with PSTN XIVIL BearerCapability element, the call is released by the 

AGCF/VGW. 
NOTE 3: The SDP answer must indicate G.71 1 not CLEARIVIODE - if not then the AGCF/VGW releases the call. 
NOTE 4: The PSTN XIVIL and SDP may be contained in the 200 OK or else stored from a 1 8X message in the same 

dialog. 



According to EN 300 403-1 [29], clause 5.12, the mapping shall be done as described in table 5.1.1.3-3. 
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Table 5.1.1.3-3: Sending of HLC fallback information 



^CONNECT 


^200 OK INVITE 


Content 


PSTN XML attachment 


HLC 


HighLayerCapability 


Progress indicator No. 5 


Progresslndicator No. 5 


NOTE 1 : If procedures of BC fallbacl< and HLC fallbacl< both require tlie sending of the progress indicator No. 5, only 

one progress indicator No. 5 is sent. 
NOTE 2: The PSTN XML may be contained in the 200 OK or else stored from a 18X message in the same dialog. 



5.1 .1 .4 Receipt of (BYE or Final Response 

Table 5.1 .1 .4-1 : Receipt (BYE or Final Response) 



^DISCONNECT 


<-BYE/3xx/4xx/5xx/6xx 


Cause information element 


Reason header 


Cause value No. X (see notes 1 and 2) 


cause value No. X 


Progress indicator No. 8 (see note 3) 

{In-band information or appropriate pattern 

now available) 




N0TE1 

NOTE 2 

NOTES 
NOTE 4 
NOTES 
NOTE 6 


If the cause value received in the Release message (BYE or Final Response) is unknown in DBS 1 , the 

unspecified cause value of the class is sent. 

Some supplementary services, such as CUG or UUS supplementary services, require the mapping of some 

causes values; see clause 5.2. 

The progress indicator is only sent if the BC received in the SETUP message is coded speech, 3, 1 l<Hz audio. 

The location is coded '1010' network beyond interworking point. 

The Progress Indicator may also be sent in a PROGRESS message. 

If the 3xx response is not filtered by the AS, it can be received by the AGCF/VGW. 



The handling of the other parameters is described in clause 5.2. 

The receipt of the release message (BYE or Final Response) during the user suspend/resume procedure is described in 
clause 5.2. 

NOTE: For providing tones/announcements in the disconnect indication state (EN 300 403-1 [29]), three 
possibilities are applicable: 

1) Provision of tones/announcements by the AGCF autonomously. 

2) Provision of tones/announcements under the control of the AS, for which the impact on the 
AGCF/VGW is the receipt of either a reIN VITE or REFER. 

3) The AGCFA'GW has a pre-configured URI of the MRFC and establishes a session for providing 
the tones/announcements. The session to the MRFC is terminated with a BYE when a RELEASE 
message is sent or received from/to the DSS 1 user. 

If a Reason header is included in a 4XX, 5XX, 6XX final response, then the Cause Value of the Reason header shall be 
mapped to the DSSl Cause Value sub-field in the DISCONNECT message. Otherwise coding of the Cause parameter 
value in the DISCONNECT message is derived from the SIP Status code received according to table 5.1.1.4-2. The 
Cause Values are defined in ETSI endorsement of ITU-T Recommendation Q.850 [27]. 
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Table 5.1.1.4-2: 3xx/4xx/5xx/6xx Received on SIP side of 0-AGCF/VGW 



^DISCONNECT (cause value) 


<-3xx/4xx/5xx/6xx SIP final responses 


127 (interworking unspecified) 


400 Bad Request 


127 (interworl<ing unspecified) 


401 Unauthorized 


127 (interworl<ing unspecified) 


402 Payment Required 


127 (interworl<ing unspecified) 


403 Forbidden 


1 (Unallocated number) 


404 Not Found 


127 (interworking unspecified) 


405 Method Not Allowed 


127 (interworking unspecified) 


406 Not Acceptable 


127 (interworking unspecified) 


407 Proxy authentication required 


127 (interworking unspecified) 


408 Request Timeout 


22 (Number changed) 


410 Gone 


127 (interworking unspecified) 


413 Request Entity too long 


127 (interworking unspecified) 


414 Request-URI too long 


127 (interworking unspecified) 


415 Unsupported Media type 


127 (interworking unspecified) 


416 Unsupported URI scheme 


127 (interworking unspecified) 


420 Bad Extension 


127 (interworking unspecified) 


421 Extension required 


127 (interworking unspecified) 


423 Interval Too Brief 


24 (call rejected due to ACR 
supplementary service) 


433 Anonymity Disallowed 


20 Subscriber absent 


480 Temporarily Unavailable 


127 (interworking unspecified) 


481 Call/Transaction does not exist 


127 (interworking unspecified) 


482 Loop detected 


127 (interworking unspecified) 


483 Too many hops 


28 (Invalid Number format) 


484 Address Incomplete 


127 (interworking unspecified) 


485 Ambiguous 


17 (User busy) 


486 Busy Here 


127 (Interworking unspecified) or 
not interworked (see note 1 ) 


487 Request terminated 


127 (interworking unspecified) 


488 Not acceptable here 


127 (interworking unspecified) 


493 Undecipherable 


127 (interworking unspecified) 


500 Server Internal error 


127 (interworking unspecified) 


501 Not implemented 


127 (interworking unspecified) 


502 Bad Gateway 


127 (interworking unspecified) 


503 Service Unavailable 


127 (interworking unspecified) 


504 Server timeout 


127 (interworking unspecified) 


505 Version not supported 


127 (interworking unspecified) 


513 Message too large 


127 (interworking unspecified) 


580 Precondition failure 


17 (User busy) 


600 Busy Everywhere 


21 (Call rejected) 


603 Decline 


1 (unallocated number) 


604 Does not exist anywhere 


127 (interworking unspecified) 


606 Not acceptable 


NOTE 1 : No interworking if the 0-AGCF previously issued a CANCEL request for 

the INVITE. 
NOTE 2: The 4xx/5xx/6xx SIP responses that are not covered in this table are not 

interworked (i.e. mapped to cause 127). 
NOTE 3: The 3xx responses are not interworked (i.e. mapped to cause 127). 
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5.1.1.5 Sending of (BYE or CANCEL) 

Table 5.1.1.5-1: Call clearing from the user 



DISCONNECT, 

RELEASE 

RELEASE COMPLETE^ 


BYE/CANCEL^ 


Cause information element 


Reason header 


Cause value No. X 


cause value No. X 
(see notes 1 and 2) 


NOTE 1 : If the cause value received in the DSS 1 message is unknown in ISUP, the unspecified cause value of the 

class is sent. 
NOTE 2: Some supplementary services, such as GUG or UUS supplementary services, require the mapping of some 

cause values; see clause 5.2. 



5.1 .1 .6 Use of Overlap Signalling (Optional) 

If Overlap Signalling is supported between the AGCF/VGW and the originating PES Application Server the Overlap 
Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within annexes G 
and H is dependent on national or network operator option. 

5.1 .2 Actions at the Incoming AGCF/VGW 
5.1.2.1 Sending of the SETUP message 

On reception of a SIP INVITE, the AGCFA^GW shall send an SETUP message. 

An AGCF/VGW shall support both incoming INVITE requests containing SIP preconditions and lOOrel extensions in 
the SIP Supported or Require headers, and INVITE requests not containing these extensions. 

If the SDP in the received INVITE request contains preconditions not met, the AGCF/VGW shall delay sending the 
SETUP until the SIP preconditions are met. 

The AGCF/VGW shall reject an INVITE request for a session only containing unsupported media types by sending a 
status code 488 (Unsupported media type). If several media streams are contained in a single INVITE request, the 
AGCF/VGW shall select one of the supported media streams, reserve the codec(s) for that media stream, and reject the 
other media streams and unselected codecs in the SDP answer, as detailed in RFC 3264 [52]. If supported audio media 
stream(s) and supported non-audio media stream(s) are contained in a single INVITE request, an audio stream should 
be selected. 

The AGCF/VGW shall include a To tag in the first backward non-100 provisional response, in order to establish an 
early dialog as described in RFC 3261 [53]. 

The information elements carried in the PSTN XML attachment of the INVITE are taken into account whatever the 
order of receipt, except when two bearer capability and/or two high layer compatibility information elements are 
received: the order of these two information elements shall be treated according to EN 300 403-1 [29], see 
table 5.1.2.1-1. 

Only the information elements involved in the interworking are described hereafter. 

The information elements used for the supplementary services are described in clause 5.2. 

For the case a PSTN XML SendingCompletelndicator is received in an INVITE, a Sending Complete information 
element is contained in the SETUP and INFO, timer T304 is not started. 

Bearer capability 

NOTE: The message side and direction has been changed to be in-line with the usual mapping as in 
EN 300 899-1 [2] ISUP-DSSl. 
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Table 5.1.2.1-1 : Coding of the Bearer Capability information element (BC) 



INVITE^ 


SETUPS 


Content 


Bearer capability information element 


PSTN XML BearerCapability 


BC information is taken from PSTN XML BearerCapability 


PSTN XML BearerCapability 1 

Speech, or 

3, 1 kHz audio 
PSTN XML BearerCapability 2 

Unrestricted digital information witii tones and 

announcements 


First BC information is derived from first PSTN XML 
BearerCapability (see note 1) 

Second BC information is derived taken from second PSTN 
XML BearerCapability (see note 1) 


No PSTN XML BearerCapability 


See table 5.1.2.1-2 


NOTE 1 : BC 1 is the bearer capability information element sent in first position in the SETUP message, BC 2 in second 
position. Bearer capability information elements shall be sent in ascending order of priority as described in 
section 5.1 1.2.1/Q.931 [54]. 

NOTE 2: Basic coding of the Bearer Capability IE. 



If the INVITE does not contain SDP information but a bearer capability information in the PSTN XML body is present, 
this is an error and the call shall be rejected with the status code 606. If the INVITE message does not contain any 
bearer information (neither bearer info in SDP nor in PSTN XML body), the AGCF/VGW may postpone the sending of 
the SETUP message. The AGCF/VGW may send a SDP offer including a media description, the content of which is 
determined using local policy within a 183 (Session Progress) response message. The SETUP message shall then be 
sent when the AGCF/VGW has received sufficient information to create the BC/HLC, else the call shall be cleared with 
status code 606. 
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Table 5.1.2.1-2: Coding of from SDP: SIP to DSS1 



m= line 


b= line (see note 4) 


a= line 


BC IE (normative) (see note 1) 


HLC parameter 
(optional) 


<media> 


<transport> 


<fmt-list> 


<modifier>:<bandwi 
dth-value> 
(see note 5) 


Rtpmap:<dynamic-PT> 

<encoding name>/<clock 

rate>/encoding parameters> 


Information 
Transport 
Capability 


User Information 

Layer 1 Protocol 

Indicator 


High Layer 

Characteristics 

Identification 


Audio 


RTP/AVP 





N/A or up to 64 kbit/s 


N/A 


"3.1 kHz audio" 


"G.711 A-law" 


(see note 3) 


Audio 


RTP/AVP 





N/A or up to 64 kbit/s 


N/A 


"3.1 kHz audio" 


"G.71 1 jj-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> 
PCMU/8000 


"3.1 kHz audio" 


"G.711 A-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> 
PCMU/8000 


"3.1 kHz audio" 


"G.71 1 fj-law" 


(see note 3) 


Audio 


RTP/AVP 


8 


N/A or up to 64 kbit/s 


N/A 


"3.1 kHz audio" 


"G.711 A-law" 


(see note 3) 


Audio 


RTP/AVP 


8 


N/A or up to 64 kbit/s 


N/A 


"3.1 kHz audio" 


"G.711 ij-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> 
PC MA/8000 


"3.1 kHz audio" 


"G.711 A-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> 
PC MA/8000 


"3.1 kHz audio" 


"G.711 u-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT, 


AS: 64 kbit/s 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 


"Unrestricted 
digital inf. 
W/tone/ann. " 
(see notes 6 and 7) 


IVIapped from tlie 
PSTN XIVIL 
attactiment 


Mapped from the PSTN 
XML attachment 


Audio 


RTP/AVP 


Dynamic 
PT 


AS: 64 kbit/s 


Rtpmap:<dynamic-PT> 
CLEARMODE/8000 
(see note 2) 


"Unrestricted digital 
information" 


IVIapped from ttie 
PSTN XML 
attachment 




Image 


UdptI 


t38 [56] 


N/A or up to 64 kbit/s 


Based on ITU-T Rec. T.38 [56] 


"3.1 kHz audio" 


"G.711 A-law" 


"Facsimile Group 2/3" 


Image 


TcptI 


t38 [56] 


N/A or up to 64 kbit/s 


Based on ITU-T Rec. T.38 [56] 


"3.1 kHz audio" 


"G.711 A-law" 


"Facsimile Group 2/3" 


Image 


UdptI 


t38 [56] 


N/A or up to 64 kbit/s 


Based on ITU-T Rec. T.38 [56] 


"3.1 kHz audio" 


"G.711 ^-law" 


"Facsimile Group 2/3" 


Image 


TcptI 


t38 [56] 


N/A or up to 64 kbit/s 


Based on ITU-T Rec. T.38 [56] 


"3.1 kHz audio" 


"G.71 1 iJ-law" 


"Facsimile Group 2/3" 


NOTE 1 : In this table the codec G.71 1 is used only as an example. Other codecs are possible. 

NOTE 2: CLEARMODE is specified in RFC 4040 [51]. 

NOTE 3: HLC is normally absent in this case. It is possible for HLC to be present with the value "Telephony", although clause 6.3.1/0.939 [55] indicates that this 

would normally be accompanied by a value of "Speech" for the Information Transfer Capability element. 
NOTE 4: If the b=line indicates a bandwidth greater than 64 kbit/s then the call may use compression techniques or reject the call with a 41 5 response indicating 

that only one media stream of 64 kbit/s is supported. 
NOTE 5: <bandwidth value> for <modifier> of AS is in units of kbit/s. 

NOTE 6: The mapping of the "Information Transport Capability" to the proper codec is explained in annex B. 
NOTE 7: The value "Unrestricted digital inf. w/tones/ann" should only be used if the Clearmode codec appears together with speech codecs in the same m-line. 
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Progress indicator 



Table 5.1.2.1-3: Coding of the progress indicator information element 



INVITE^ 


SETUPS 




Progress indicator information element 


PSTN XML attachment 


Progresslndicator. No. (Value of PI) 
and PSTN XML and 
Progresslndicator No.6 (see note 2) 


Progress indicator No. Value of PI (see note 1) 


Progresslndicator No.6 (see note 2) 




No PSTN XML 


Progress indicator No. 1 


NOTE 1 : Except value No. 6 which is not defined in EN 300 403-1 [29]. 

NOTE 2: The ISDN access indicator - "originating access ISDN" is transported in the 

IMS as PSTN XML Progresslndicator No.6 and is not sent to the access, see 

annex E. 



Low layer compatibility 

If the low layer compatibility information element is present in the PSTN XML attachment, LowLayerCompatibility of 
the INVITE, it is converted into the LLC in the SETUP message. 

High layer compatibility 

If the high layer compatibility information element is present in the PSTN XML attachment, HighLayerCompatibility 
of the INVITE, it is converted into the HLC in the SETUP message. 

If two high layer compatibility information elements are received in the PSTN XML attachment, 

HighLayerCompatibility of the INVITE, they are converted into the HLC in the same order in the SETUP message (the 
meaning of HLC order is described in 5.12.3.2/Q.931 [54]). 

Calling party number 

See clause 5.2. 

Calling party subaddress 

See clause 5.2. 

Called party subaddress 

See clause 5.2. 
User-user 

See clause 5.2. 

Table 5.1.2.1-4: Mapping SIP Request-URI to DSS1 Called Party Number 



INVITE 


SETUP 


Request-URI 


Called Party Number 


E1 64 Address 

(format "+"CC+NDC+SN) 

(e.g. as User info in SIP URI with user= phone, or as tel URI) 


Type of number 




National number 
NDC+SN 


International number 
"+"CC+NDC+SN 


Subscriber number 
SN 
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5.1 .2.2 Sending of the 1 8x from the destination VGW/AGCF 

Table 5.1.2.2-1: Interworking of CALL PROCEEDING/PROGRESS 



<- Message on the SIP 
183 Session Progress 


<-Message sent to the DBS 1 
CALL PROCEEDING / PROGRESS 




Progress indicator information element 


PSTN XML with Progresslndicator Value of PI 

and 

PSTN XML Progresslndicator No. 7 (see note 2) 


No. Value of PI 


PSTN XML Progresslndicator No. 7 (see note 2) 




NOTE 1 : The P-Earl-Media header is only sent If the BearerCapablllty received In the INVITE message Is 

coded speech, 3, 1 kHz audio. 
NOTE 2: The ISDN access Indicator - "Terminating access ISDN" Is transported In the IMS as PSTN XML 

Progresslndicator No.7, see annex E. 



The SDP answer is described in annex B. 

If en bloc sending is used on the DSS 1 side, the SETUP message shall contain all the information required by the 
called user to process the call. 

If overlap sending is used, and if the SETUP message has already be sent and the SETUP ACKNOWLEDGE message 
received, an INFORMATION message is sent upon receipt of each Subsequent INVITE message. 

The following cases are possible trigger conditions of sending the 18x message: 

a) The destination VGW/AGCF has determined independently of access indications that the complete called 
party number has been received, a 183 Session Progress is sent. 

b) Overlap receiving is used on the DSS 1 side and a CALL PROCEEDING is received, a 183 Session Progress 
is sent. 

c) En bloc receiving is used on the DSS 1 side and a Progress indicator information element is received in a 
CALL PROCEEDING message or in a PROGRESS message, a 183 Session Progress is sent, (except with 
value No. 8, in-band information or an appropriate pattern is now available. No. 3, originating address is 
non-ISDN is received in a CALL PROCEEDING message or in a PROGRESS message, a 183 Session 
Progress is sent. 

d) The first ALERTING message is received a 180 Ringing is sent. 

e) It has been determined, in case of call failure, that a special in-band tone or announcement has to be returned 
to the calling party from the destination VGW/AGCF, a 183 Session Progress is sent. 

On speech or 3,1 kHz calls, the awaiting answer indication (e.g. ring tone) is sent to the calling party upon receipt of the 
first ALERTING message. 

Table 5.1.2.2-2: Interworking of ALERTING 



<-180 Ringing 


^ ALERTING 




Progress indicator information element 


PSTN XML with Progress indicator Value of PI 

and 
PSTN XML Progresslndicator No. 7 (see note 2) 


No. Value of PI 


P-Early-Media header 
PSTN XML with Progress indicator 8 (see note 1) 




PSTN XML Progresslndicator No. 7 (see note 2) 




NOTE 1 : The P-Earl-Media header is only sent If the BearerCapablllty received In the INVITE message Is 

coded "speech", "3,1 kHz audio". 
NOTE 2: The ISDN access Indicator - "Terminating access ISDN" Is transported In the IMS as PSTN XML 

Progresslndicator No.7, see annex E. 



The SDP answer is described in annex B. 
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If the 180 Ringing has already been sent^ the following cases are possible trigger conditions of sending the 183 Session 
Progress: 

a) It has been determined, in case of call failure, that a special in-band tone or announcement has to be returned 
to the calling party from the destination VGW/AGCF. 

b) It has been determined that an in-band tone or announcement has to be returned to the calling party from the 
destination VGW/AGCF. 

Table 5.1.2.2-3: Contents of 183 Session Progress message 
if a 180 Ringing has already been sent 



<r- Message on the SIP 
183 Session Progress 



P-Early-Media header 
PSTN XML with Progress indicator 8 (see note 1) 



NOTE 1 : The P-Earl-Media header is only sent if the PSTN XML BearerCapability received in the INVITE 

message is coded speech, 3, 1 kHz audio. 
NOTE 2: This ensures that the originating side receives an indication that the terminating access is ISDN. 



MANDATORY PARAMETERS 

None. 

OPTIONAL PARAMETERS 

The P-Early-Media header authorization of early media if it has been determined, that an in-band tone or announcement 
has to be returned to the calling party from the destination gateway. 

NOTE: Tones and announcements can as well provided by the MRFC. 

PSTN XML attachment HLC, LLC, Progress indicator, etc 

This extension carries the progress indicator information element possibly received from the called user (except the 
value No. 8). 

It may carry other information element as well: see clause 5.2 and tables 5.1.2.2-4 and 5.1.2.2-5. 

History-Info header 

See clause 5.2. 

Handling of fallback information (only applicable at T reference point) 

When the terminating gateway has knowledge that the fallback capability was requested in the Initial INVITE, and if no 
progress indicator No. 1 or No. 2 has been received from the DSS 1 side, tables 5.1.2.2-4 and 5.1.2.2-5 are applicable. 

Table 5.1.2.2-4: Handling of BC fallback information 



^18x 


<-Message received from 
the access 


PSTN XML attachment 


Content 


BearerCapability derived from received DSS1 BC 
(speech or 3, 1 kHz audio) 
Progresslndicator. No. 5 


BClow 

(speech or 3, 1 kHz audio) 

p.i. No. 5 



The SDP answer is described in annex B. 
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Table 5.1.2.2-5: Handling of HLC fallback information 



^18x 


<-Message received from the access 


PSTN XML attachment 


Content 


HighLayerCompatibility 
Progresslndicator. No. 5 


HLC 
Progress indicator No. 5 



The SDP answer is described in annex B. 

5.1.2.3 Sending of the 200 OK INVITE 

Upon receipt of the CONNECT message, the destination AGCFNGW shall: 

• stop the sending of the awaiting answer indication (if any); 

• send the 200 OK INVITE to the preceding entity. 

NOTE: Tones and announcements can as well provided by the MRFC. 
The 200 OK INVITE is coded as follows: 
OPTIONAL PARAMETERS 
P-Asserted-Identity 
See clause 5.2. 

A second identity is also delivered in a changed From header in an UPDATE request, in detail described in clause 5.2.2. 
PSTN XML attachment 

Table 5.1.2.3-1 : Contents of the PSTN XML attachment 



^ 200 OK INVITE 


^CONNECT 


PSTN XML attachment 


Information elements 


Progresslndicator No (Value of PI) 

and 

Progresslndicator No 7 (see annex E) 


Progress indicator No. Value of PI 


LowLayerCompatibility 

and 

Progresslndicator No 7 (see annex E) 


Low layer compatibility 


High layer compatibility 

and 

Progresslndicator No. 7 (see annex E) 


High layer compatibility 


Bearer Capability 

and 

Progresslndicator No. 7 (see annex E) 


Bearer Capability 


Progresslndicator No 7 (see annex E) 





It may carry other information elements as well: See clause 5.2 and tables 5.1.2.3-2 to 5.1.2.3-5. 

The SDP answer is described in annex B. 

Handling of fallback information 

When the terminating AGC/WGW has knowledge that the fallback capability was requested in the Initial INVITE, and 
if no progress indicator No. 1 or No. 2 has been received from the DSS 1 side, tables 5.1.2.3-2 to 5.1.2.3-5 are 
applicable. 
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Coincident S and T reference point 

Table 5.1.2.3-2: Handling of BC fallback information Coincident S and T reference point 



^ 200 OK INVITE 


^CONNECT 


PSTN XML attachment 


Content 


BearerCapability 

(unrestricted digital information witli tones and 

announcements) 


BC 

(unrestricted digital information with tones and 
announcements) 


BearerCapability 
(speech or 3,1 kHz audio) 


BC 

(speech or 3,1 kHz audio) 


BearerCapability received in the PSTN XML 
attachment of the received INVITE request 
(speech or 3,1 kHz audio) 


NoBC 



The SDP answer is described in annex B. 

Table 5.1.2.3-3: Handling of HLC fallback information Coincident S and T reference point 



<-200 OK INVITE 


^-CONNECT 


PSTN XML attachment 


Content 


HighLayerCompatibility 


HLC 


HighLayerCompatibility received in first position in 
the PSTN XML attachment of the INVITE request 


No HLC 



The SDP answer is described in annex B. 
T reference point 



Table 5.1.2.3-4: Handling of BC fallback information T reference point 



^ 200 OK INVITE 


^CONNECT 


PSTN XML attachment 


Content 


BearerCapability 

(unrestricted digital information with tones and 

announcements) 


BC 

(unrestricted digital information with tones and 

announcements) 


BearerCapability 
(speech or 3,1 kHz audio) 


BC 

(speech or 3,1 kHz audio) 


BearerCapability 
(speech or 3,1 kHz audio) 
Progresslndicator. No. 5 


BC 

(speech or 3,1 kHz audio) 

p.i. No. 5 


BearerCapability received in the PSTN XML attachment 
of the INVITE request 
(speech or 3,1 kHz audio) 
Progresslndicator No. 5 


No BC (see note) 


NOTE: In this case, the fallback information coded in the PSTN XML attachment are not repeated if 
already sent in a previous backward message. 



The SDP answer is described in annex B. 

Table 5.1.2.3-5: Handling of HLC fallback information T reference point 



<-200 OK INVITE 


<-CONNECT 


PSTN XML attachment 


Content 


HighLayerCompatibility 


HLC 


HighLayerCompatibility 
Progresslndicator No. 5 


HLC 
Progress indicator No. 5 


No HighLayerCompatibility 


No HLC 



The SDP answer is described in annex B. 
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5.1.2.4 



Receipt of BYE/CANCEL 



Table 5.1.2.4-1 : Receipt of BYE/CANCEL 



BYE/CANCEL^ 


DISCONNECT -^ 


Reason header 


Cause information element 


cause No. X 


Cause value No. X 
(see notes 1 and 2) 


NOTE 1 : If the Reason value received in the Release message (BYE/CANCEL) is unknown in DSS 1 , the 

unspecified cause value of the class is sent. 
NOTE 2: Some supplementary services, such as CUG or UUS supplementary services, require the mapping 

of some cause values: see clause 5.2. 
NOTE 3: The location is coded '1010' network beyond interworking point. 



The handling of the other parameters is described in clause 5.2. 



5.1.2.5 



Sending of BYE/4xx/5xx 



If a DISCONNECT, RELEASE or RELEASE COMPLETE message is received and a final response (i.e. 200 OK 
(INVITE)) has already been sent, the I-AGCF/VGW shall send a BYE message. "The Cause Value sub-field 
received in the DISCONNECT, RELEASE or RELEASE COMPLETE message shall be mapped to the 
cause value of the Reason header of the BYE message". 

If the DISCONNECT, RELEASE or RELEASE COMPLETE message is received and the final response (i.e. 200 OK 
(INVITE)) has not already been sent, the I-AGCF/VGW shall send a Status-Code 4xx (Client Error) or 5xx (Server 
Error) response. The Status code to be sent is determined by examining the Cause code value received in the 
DISCONNECT, RELEASE or RELEASE COMPLETE message. Table 5.L2.5-2 specifies the mapping of the cause 
code values to SIP response status codes. Cause code values not appearing in the table shall have the same mapping as 
the appropriate class defaults according to the ETSI endorsement of ITU-T Recommendation Q.850 [27]. 

Table 5.1.2.5-1: Call clearing during call establishment 



<- BYE/4XX/5XX 


^DISCONNECT 

RELEASE 

RELEASE COMPLETE 

(see note 1) 


Reason header 


Cause information element 


cause No. X (see note 2) 


Cause value No. X 


NOTE 1 : In case of coincident S and T reference point, 5.2.5.3/0.931 [54] describes how these messages are 

taken into account when they are received during call establishment. 
NOTE 2: If the cause value received in the DSS 1 message is unknown in ISUP, the unspecified cause value 

of the class is sent. 
NOTE 3: Some supplementary services, such as CUG or UUS supplementary services, require the mapping 

of some cause values: see clause 5.2. 



The handling of the other parameters possibly present in the Release message BYE or 4xx/5xx is described in 
clause 5.2. 

Table 5.1.2.5-2: Receipt of DISCONNECT, RELEASE or RELEASE COMPLETE message 



<-SIP final response 


<- DISCONNECT, RELEASE, RELEASE COMPLETE 


Status code 


Cause value 


404 Not Found 


Cause value No. 1 (unallocated (unassigned) number) 


500 Server Internal error 


Cause value No 2 (no route to network) 


500 Server Internal error 


Cause value No 3 (no route to destination) 


500 Server Internal error 


Cause value No. 4 (Send special information tone) 


404 Not Found 


Cause value No. 5 (Misdialled trunk prefix) 


486 Busy Here 


Cause value No. 1 7 (user busy) 


480 Temporarily 
unavailable 


Cause value No 18 (no user responding) 
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<-SIP final response 


<r- DISCONNECT, RELEASE, RELEASE COMPLETE 


Status code 


Cause value 


480 Temporarily 
unavailable 


Cause value No 19 (no answer from the user) 


480 Temporarily 
unavailable 


Cause value No. 20 (subscriber absent) 


603 Decline 


Cause value No 21 (call rejected), Location = 000 / user (U) 


480Temporarily 
unavailable 


Cause value No 21 (call rejected) , Location <> 000 / user (U) 


410 Gone 


Cause value No 22 (number changed) 


433 Anonymity 
Disallowed 


Cause value No. 24 (call rejected due to ACR supplementary service) 


480 Temporarily 
unavailable 


Cause value No 25 (Exchange routing error) 


502 Bad Gateway 


Cause value No 27 (destination out of order) 


484 Address Incomplete 


Cause value No. 28 invalid number format (address incomplete) 


500 Server Internal error 


Cause value No 29 (facility rejected) 


480 Temporarily 
unavailable 


Cause value No 31 (normal unspecified) (class default) (see note) 


486 Busy here if CCBS- 

T-Available invoke 

component is present) 

else 480 Temporarily 

unavailable 


Cause value in the Class 010 (resource unavailable, Cause value No 34) 


500 Server Internal error 


Cause value in the Class 01 

(resource unavailable. Cause value No's. 38, 41 , 42, 43, 44, & 47) 

(47 is class default) 


500 Server Internal error 


Cause value No 50 (requested facility no subscribed) 


500 Server Internal error 


Cause value No 57 (bearer capability not authorised) 


500 Server Internal error 


Cause value No 58 (bearer capability not presently) 


500 Server Internal error 


Cause value No 63 (service option not available, unspecified) 
(class default) 


500 Server Internal error 


Cause value in the Class 100 (service or option not implemented. Cause value 
No's. 65, 70 & 79) 79 is class default 


500 Server Internal error 


Cause value No 88 (incompatible destination) 


404 Not Found 


Cause value No 91 (invalid transit network selection) 


500 Server Internal error 


Cause value No 95 (invalid message) 
(class default) 


500 Server Internal error 


Cause value No 97 (Message type non-existent or not implemented) 


500 Server Internal error 


Cause value No 99 (information element/parameter non-existent or not 

implemented)) 


480 Temporarily 
unavailable 


Cause value No. 102 (recovery on timer expiry) 


500 Server Internal error 


Cause value No 1 10 (Message with unrecognised Parameter, discarded) 


500 Server Internal error 


Cause value No. 1 1 1 (protocol error, unspecified) 
(class default) 


480 Temporarily 
unavailable 


Cause value No. 127 (interworking unspecified) 
(class default) 


NOTE: Glass 1 and class 2 have the same default value. 



5.1.2.6 



Sending of the DSS1 INFO (Optional) 



If Overlap Signalling is supported between the AGCF/VGW and the terminating PES Application Server the Overlap 
Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within annex D 
and annex E is dependent on national or network operator option. 
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5.2 Supplementary services 

This clause discusses the impact of supplementary services on the AGCF/VGW. Table 5.2-1 lists the supplementary 
services covered and the corresponding references to the PES simulation service specifications. 

Table 5.2-1 : PES Simulation Supplementary Services 



5.2.1.1.2 



Supplementary Service 


Reference 


Communication Hold (HOLD) 


[101 


Connected Line Identification Presentation (COLP) & 
Connected Line Identification Restriction (COLR) 


[7] 


Calling Line Identification Presentation (CLIP) & 
Calling Line Identification Restriction (CLIR) 


[6] 


Conference Call (CONF) 


[91 


Communication Diversion Services (CDIV) 


[81 


IVIalicious Call Identification (MCID) 


[461 


Explicit Call Transfer (ECT) 


[361 


Subaddressing (SUB) 




Closed User Group (CUG) 


[281 


User-to-User Signalling (UUS) 




Communication Waiting (CW) 


[581 


Terminal Portability (TP) 




Three Party (3PTY) 


[9] 


Completion of Communications to Busy Subscriber 

(CCBS) & 

Completion of Communications by No Reply (CCNR) 


[591 


Advice of Charge (AOC) 


[311 


Message Waiting Indication (MWI) 


[261 



5.2.1 Communication Hold (HOLD) 

5.2.1 .1 Actions at the Incoming AGCF/VGW 

5.2.1 .1 .1 Notification received from the networl< 

Table 5.2.1.1.1-1: HOLD notification 



INVITE/ UPDATE -^ 


NOTIFY -^ 


SDP: a=sendonly/inactive 


Notification indicator 
information element 




Notification description 


sendonly/inactive 


111 1001 
Remote hold 


sendreceive 


111 1010 
Remote retrieval 



Invocation at coincident 8 and T reference point 
Table 5.2.1.1.2-1: HOLD invocation 



<-INVITE/UPDATE 


<- Message received from the DSS 1 


SDP: a=sendonly/inactive 


sendonly/inactive 


HOLD 


sendreceive 


RETRIEVE 
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5.2.1 .1 .3 Notification received at T reference point 

A HOLD notification may be received at T reference point in the active phase of the call. 

Table: 5.2.1 .1 .3-1 : Receipt of a HOLD notification from a private networit 



<-INVITE/UPDATE 


<-NOTIFY 


SDP: a=sendonly/inactive 


Notification indicator 
information element 




Notification description 


sendonly/inactive 


111 1001 
Remote hold 


sendreceive 


111 1010 
Remote retrieval 



5.2.1.2 Actions at the outgoing AGCF/VGW 

5.2.1 .2.1 Notification received from the networl< 

Table 5.2.1.2.1-1 : Receipt of HOLD notification from the network 



<-NOTIFY 


<-INVITE/UPDATE 


Notification indicator information element 


SDP: a=sendonly/inactive 


Notification description 




111 1001 
Remote hold 


sendonly/inactive 


111 1010 
Remote retrieval 


sendreceive 



5.2.1.2.2 



Invocation at coincident S and T reference point 
Table 5.2.1.2.2-1: HOLD invocation 



Message received from 
the DSS 1 -^ 


INVITE/UPDATE^ 


SDP: a=sendonly/inactive 




HOLD 


sendonly/inactive 


RETRIEVE 


sendreceive 



5.2.1 .2.3 Notification received at T reference point 

A HOLD notification may be received at T reference point in the active phase of the call. 

Table 5.2.1.2.3-1 : Receipt of a HOLD notification from a private network 



NOTIFY^ 


INVITE / UPDATE^ 


Notification indicator 
information element 


SDP: a=sendonly/inactive 


Notification description 




111 1001 
Remote hold 


sendonly/inactive 


111 1010 
Remote retrieval 


sendreceive 
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5.2.2 Connected Line Identification Presentation (COLP) / Connected Line 
Identification Restriction (COLR) 



5.2.2.1 



Actions at the incoming AGCF/VGW 



If the Initial INVITE is received and the Supported header contains the "from-change" tag, then the 
P-Asserted-Identity in the 200 OK INVITE or UPDATE request and the changed From header in the UPDATE are sent 
as described in tables 5.2.2.1.1-1 and 5.2.2.1.1-2. 



5.2.2.1.1 



Connected Line Identification Presentation (COLP) 



The AGCF/VGW shall sent first a 200 OK INVITE including an option tag "from-change" and after then an UPDATE 
request as shown in table 5.2.2.1.1-1 according the rules of RFC 4916 [50]. 

200 OK and UPDATE is sent on the Mw interface 

Table 5.2.2.1.1-1 : Connected number interworking applies at Mw interface 



<- 200 OK INVITE 


<- UPDATE 


^-CONNECT 


Connected number IE. 






Numbering plan 
identification 


Type of number 


No "from-change" tag in the 
supported header 
P-Asserted-ldentity containing the 
value saved from the P-Called- 
Party-ID header that was received 
in the INVITE request. 


No UPDATE 


No or invalid (see note 1) connected 
number information element 


No "from-change" tag in the 
supported header 

P-Asserted-ldentity with a value, 
including the display name if 
previously stored during 
registration representing the 
terminating user indicated in the 
connected number. 


No UPDATE 


ISDN/telephony 
numbering plan 
or 
Unknown 


unknown 


Address digits 




No "from-change" tag in the 
supported header 

P-Asserted-ldentity with a value, 
including the display name if 
previously stored during 
registration representing the 
terminating user indicated in the 
connected number. 


No UPDATE 


ISDN/telephony 
numbering plan 
or 
Unknown 


Subscriber number 


Address digits 




"from-change" tag in the supported 
header 

P-Asserted-ldentity with a value, 
including the display name if 
previously stored during 
registration representing the 
terminating user indicated in the 
connected number. 


Userinfo of the changed From 
header derived from the 
Address digits in the format: sip: 
local-number-digits = Address 
digits; phone- 

context=xxxxxx@hostportion; 
user=phone (see note 2). 


ISDN/telephony 
numbering plan 
or 
Unknown 


National number 


Address digits 
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<r- 200 OK INVITE 


^ UPDATE 


^CONNECT 


Connected number IE. 






Numbering plan 
Identification 


Type of number 


"from-change" tag in the supported 
header 

P-Asserted-ldentity with a value, 
Including the display name if 
previously stored during 
registration representing the 
terminating user indicated in the 
connected number. 


Userinfo of the changed From 
header derived from the 
Address digits in the format: sip: 
global -number-digits = Address 
digits@hostportion; 
user=phone. 


ISDN/telephony 
numbering plan 
or 
unknown 


international number 


Address digits 


NOTE 1 : Validity conditions of the connected number information element are defined in 5.5.2.3/Q.951 [30]. 
NOTE 2: The combination of dialled digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 



If the "from-change" tag in the Supported header in the Initial INVITE is not received, then no UPDATE is sent. 

A P-Asserted-Identity header with the value saved from the P-Called-Party-ID header that was received in the request is 

contained in the 200 OK (INVITE). 

Connected subaddress 

If provided, the connected subaddress is transported in the changed From header field of the UPDATE request. 
200 OK and UPDATE is sent on the Gm interface 
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Table 5.2.2.1.1-2: Connected number interworking applies at Gm interface 



^ 200 OK INVITE 


<- UPDATE 


^CONNECT 


Connected number IE. 






Numbering plan 
Identification 


Type of number 


No "from-change" tag in the 
supported header 


No UPDATE 


No or invalid (see note 1) connected 
number information element 


No "from-change" tag in the 
supported header 


No UPDATE 


ISDN/telephony 
numbering plan 
or 
Unknown 


unknown 


Address digits 




No "from-change" tag in the 
supported header 


No UPDATE 


ISDN/telephony 
numbering plan 

or 

Unknown 


Subscriber 
number 


Address digits 




"from-change" tag in the supported 
header 




ISDN/telephony 
numbering plan 
or 
Unknown 


National number 


Userinfo of the changed From 
header derived from the 
Address digits in the format: 
sip: local-number-digits = 
Address digits; phone- 
context=xxxxxx@hostportion; 
user=phone (see note 2) 


Address digits 




ISDN/telephony 
numbering plan 

or 

unknown 


international 
number 




Userinfo of the changed From 
header derived from the 
Address digits in the format: 
sip: global -number-digits = 
Address digits @hostportion; 
user=phone 


Address digits 


NOTE 1 : Validity conditions of the connected number information element are defined in 5.5.2.3/Q.951 [30]. 
NOTE 2: The combination of dialled digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 



Connected subaddress 

If provided, the connected subaddress is transported in the changed From header field of the UPDATE request. 

5.2.2.1 .2 Connected Line Identification Restriction (COLR) 

Table 5.2.2.1.2-1 : Coding of the Privacy header field 



^200 OK INVITE 


^CONNECT 


Privacy header field 


Connected number 

Information element 

Presentation Indicator 


"id", "header", "user" 


Presentation restricted 


No Privacy header 


Absent 


"none" 


Presentation allowed 
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5.2.2.2 



Actions at the outgoing AGCF/VGW 



5.2.2.2.1 Connected Line Identification Presentation (COLP) 

NOTE: Depending on national regulations, some networks may define categories of subscribers that have the 
ability to override the presentation restriction and have the connected party's ISDN number, and 
subaddress information (if any) presented (e.g. the police). The ability to override the presentation 
restriction and the protocol to support such a service is a national matter. 

The option tag "from-change" is added to the supported header in the initial INVITE. 

Only one connected number information element is sent in the CONNECT message. 

If a 200 OK final response including the option tag "from-change" is received then Tjjj^^ shall be started if Userinfo of 
P-Asserted-Identify is in the format of a tel URI and no Privacy (including Privacy value of none) is present. In this 
case the interworking as described in tables 5.2.2.2.1-2 and 5.2.2.2.1-3 applies. The 200 OK INVITE to a CONNECT 
shall be held up till the UPDATE containing the changed From and To information is received and timer Tjjj^^ is 
running ELSE the 200 OK INVITE shall be mapped immediately as described within tables 5.2.2.2.1-1 and 5.2.2.2.1-2. 
At expiry of Tjjj^^ the 200 OK INVITE shall be mapped as described in table 5.2.2.2.1-2. 

If no P-Asserted-Identity header was received and no Privacy "id" or "header" was received in the 200 OK final 
response this is assumed as the originating user has not subscribed the COLP service. 

If several responses contain a P-Asserted-Identity header field, only the latest received P-Asserted-Identity header 
should be used for a Connected number sent in a CONNECT message to the calling user. 

Table 5.2.2.2.1-1 : COLP information sent to the calling user 



<-CONNECT 


<-200 OK INVITE 


COLP information sent to the calling 
user 


P-Asserted-ldentity 


Privacy header 


Supported header 


Connected number IE 
(see table 5.2.2.2.1-2) 


Userinfo in the format of a tel 
URI 


No Privacy 
present 
or 
Priv .vaiue none 


No "from-change" 


Connected number IE 
(see table 5.2.2.2.1 -3) 


Userinfo in the format of a tel 
URI 


No Privacy 
present 
or 
Priv .vaiue none 


"from-change" 


Connected number IE 

Type of number Unknown 
Numbering plan Unknown 
Presentation ind. Presentation 

restricted 
Screening ind. Network provided 
Number digits No digit 


Not present 


id or iieader 


Value non- 
significant 


No Connected number IE 


No P-Asserted-ldentity header 
field 


no Privacy 
present 


Value non- 
significant 



If the P-Asserted-Identity header is received at the AGCF/VGW it is assumed that the originating user subscribes the 
COLP supplementary service. 
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Table 5.2.2.2.1-2: Coding of the connected number information element 
according to the P-Asserted-ldentity header field 



^CONNECT 


^200 OK INVITE 


Connected number IE 


P-Asserted-ldentity 


Type of number (see note) 
National number 

International number 


userinfo 

sip: local-number-digits; phone-context=nat 
@hostportion; user=phone 

sip:global-number-digits@hostportion; 
user=phone 


Numbering plan identification 

ISDN/Telephony numbering plan 




Presentation indicator 
Presentation allowed 




Screening indicator 
Network provided 




Number digits derived from the userinfo. 
In case for global number and the country code is 
the same as the AGCF/VGW or line is located, the 
country code is removed from the number of the 
Type of number is set to "national number 




NOTE: As a network option, the type of number may be coded unknown when a prefix is added to the 
number. 



Table 5.2.2.2.1-3: Coding of the connected number information element 
according to the changed From header 



^CONNECT 


^UPDATE 


Connected number IE 


From header 


Type of number (see note) 
National number 

International number 


userinfo 

sip: local-number-digits; phone-context=nat 
@hostportion; user=phone 

sip:global-number-digits@hostportion; 
user=phone 


Numbering plan identification 

ISDN/Telephony numbering plan 




Presentation indicator 
Presentation allowed 




Screening indicator 

User provided, not verified 




Number digits derived from the userinfo. 
In case for global number and the country code is 
the same as the AGCF/VGW or line is located, the 
country code is removed from the number of the 
Type of number is set to "national number 




NOTE: As a network option, the type of number may be coded unknown when a prefix is added to the number. 
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Connected subaddress 



Table 5.2.2.2.1-4: Sending of the connected subaddress 



^CONNECT 


^UPDATE 


Content 


Changed From isub parameter 


Privacy header 


Connected subaddress 
information element 


Connected subaddress address 
string 


absent or not "id" 


No connected subaddress 
information element 


Connected subaddress address 
string 


"id" or "header" 

or 

No connected number parameter 


NOTE: As a national option, the presentation restriction indication received in the connected number 
parameter can be overridden for specific calling access' categories. In such a case, the same 
actions are taken as if presentation allowed was received. 



5.2.2.2.2 Connected line identification restriction (COLR) 

See table 5.2.2.2.1-1. 
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5.2.3 Calling line Identification Presentation (CLIP) / Calling line 
Identification Restriction (CLIR) 

5.2.3.1 Actions at the incoming AGCF/VGW 

Table 5.2.3.1-1 : Mapping of SIP From/P-Asserted-ldentity/ 
Privacy header fields to CLI parameters 



INVITE^ 


SETUPS 


P-Asserted-ldentity 


From header 


Privacy 


Coding of the calling 
party number 
Information element 


Absent 


Value not significant (see 
note) 


No Privacy header 


No Calling number IE 


Absent 


"Anonymous" 

<sip:anonymous@anonymo 

us.invalid> 


"Id" or "Header" or 
"user" 


See table 5.2.3.1-3 


Absent 


"Unavailable" 

<"sip:unavailable@unknown 

.invalid> 


No Privacy header or 
the header has other 
values than "Id" or 
"Header" or "user" 


See table 5.2.3.1-2 


User portion is in the 
format of a tel URI 


User portion is not in the 
format of a tel URI 


No Privacy header or 
the header has other 
values than "Id" or 
"Header" or "user" 


See table 5.2.3.1 -4 


User portion is in the 
format of a tel URI 


User portion is not in the 
format of a tel URI 


"Id" or "Header" or 
"user" 


See table 5.2.3.1-3 


The user portion of the P-Asserted-ldentity and the 
user portion of the From header are in the format of a 
tel URI and 

the user portion of the P-Asserted-ldentity is not equal 
to the user portion of the From header 


No Privacy header or 
the header has other 
values than "Id" or 
"Header" or "user" 


The calling party number 
information element is 
repeated with one 
occurrence encoded 
according to 
table 5.2.3.1-4 and the 
other occurrence 
according to 
table 5.2.3.1-5 


The user portion of the P-Asserted-ldentity and the 
user portion of the From header are in the format of a 
tel URI and 

the user portion of the P-Asserted-ldentity is equal to 
the user portion of the From header 


No Privacy header or 
the header has other 
values than "Id" or 
"Header" or "user" 


See table 5.2.3.1-4 


User portion is in the 
format of a tel URI 


User portion is in the format 
of a tel URI 


"Id" or "Header" or 
"user" 


See table 5.2.3.1-3 


NOTE: The Application Server may as a network option set the contents of the From header to a default 
non significant value which is different from the values in the list bellow: 
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag= xxxxxxx 
From: "Unavailable" <"sip:unavailable@unknown.invalid>;tag= xxxxxxx. 



If no P-Asserted-Identity header is received at the AGCF/VGW it is assumed that the terminating user does not 
subscribe the CLIP supplementary service. 

Table 5.2.3.1-2: Calling party number not presented due to interworking to the called user 



Calling party number IE 


Type of number 


Unknown 


Numbering plan identification 


Unknown 


Presentation indicator 


Not available due to interworking 


Screening indicator 


Network provided 


Number digits 


No digits 
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Table 5.2.3.1-3: Calling party number not presented due to presentation restriction to the called user 



Calling party number IE 


Type of number 


Unknown 


Numbering plan identification 


Unknown 


Presentation indicator 


Presentation restricted 


Screening indicator 


Network provided 


Number digits 


No digits 



Table 5.2.3.1-4: Coding of the calling party number information element 
according to the P-Asserted-ldentity header field 



INVITE^ 


SETUPS 


P-Asserted-ldentlty header 


Calling party number IE 


sip: local-number-digits; 

phone-context=nat @hostportion; user=phone 


Type of number (see note) 
National number 


sip:global-number-digits@hostportion; 
user=phone 


Type of number (see note) 
International number 




Numbering plan identification 

ISDN/Telephony numbering plan 


Presentation indicator 
Presentation allowed 


If the userinfo of the From header field is equal to the 
userinfo in the P-Asserted-ldentity 


Screening indicator 

User provided, verified and passed 


If the userinfo of the From header field is not equal to 
the userinfo in the and P-Asserted-ldentity 


Screening indicator 
Network provided 




Number digits are derived from user portion. 
In case for global number and the country code is the 
same as the AGCF/VGW or line is located, the country 
code is removed from the number of the Type of 
number is set to "national number" 


NOTE: As a network option, the type of number may be coded unknown when a prefix is added to the number. 



Table 5.2.3.1-5: Coding of the calling party number information element 
according to the From header field 



INVITE^ 


SETUPS 


From header field 


Calling party number IE 


sip: local-number-digits; 

phone-context=nat @hostportion; user=phone 


Type of number (see note) 
National number 


sip: global-number-digits @hostportion; 
user=phone 


Type of number (see note) 
International number 




Numbering plan identification 

ISDN/Telephony numbering plan 




Presentation indicator 
Presentation allowed 




Screening indicator 

User provided, not verified 




Number digits are derived from user portion. 
In case for global number and the country code is the 
same as the AGCF/VGW or line is located, the country 
code is removed from the number of the Type of 
number is set to "national number" 


NOTE: As a network option, the type of number may be coded unknown when a prefix is added to the number. 
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5.2.3.2 Actions at the outgoing AGCF/VGW 

Actions at the Gm interface 

Table 5.2.3.2-1 : Mapping CLI parameters to SIP header fields - Gm interface 



SETUPS 


INVITE^ 


Presentation 

Restriction 

Indicator 


P-Preferred-ldentity 
header field 


From header field: 


Privacy 

header 

field 


Privacy 
value 


Presentation 
restricted 


Addr-spec is derived 
from Calling Party 
Number parameter 
Address Signals 
(see note 1) 


Addr-spec is derived from Calling 

Party Number parameter Address 

Signals 

or (see note 2) 

"anonymous@anonymous. invalid" 


Y 


"id" and 

"header" 

and "user" 


Presentation 
restricted 

(see note 3) 


Default registered 
public identity 
associated with calling 
party is used 


"unavailable@unknown. invalid" 


Y 


"id" and 

"header" 

and "user" 


Absent 


Default registered 
public identity 
associated with calling 
party is used 


"unavailable@unknown. invalid" 


N/Y (see 
note 2) 


If present: 
"id" and 
"header" 

and "user" 


Allowed 


Addr-spec is derived 
from Calling Party 
Number parameter 
Address Signals 
(see note 1) 


Addr-spec is derived from Calling 
Party Number parameter Address 
Signals 
(see note 1) 


Y 


"none" 


NOTE 1 : IVIapping CLI parameters to SIP header fields see table 5.2.3.2-3. 

NOTE 2: As network option. 

NOTE 3: Calling party number available but number digits are not included. 
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Actions at the Mw interface 



Table 5.2.3.2-2: Mapping CLI parameters to SIP header fields - Mw interface 



SETUPS 


INVITE^ 


Presentation 

Restriction 

Indicator 


P-Asserted-ldentity 
header field 


From header field 


Privacy 

header 

field 


Privacy 
value 


Presentation 
restricted 


Addr-spec: calling 
party number address 
signal is matched with 
one of the public user 
identities else if no 
matched the default 
public user identity is 
used 


Addr-spec is derived from Calling 

Party Number parameter Address 

Signals 

or (see note 2) 

"anonymous@anonymous. invalid" 


Y 


"id" and 

"header" 

and "user" 


Presentation 
restricted 

(see note 3) 


Addr-spec is the 
default public user 
identity 


"unavailable@unknown. invalid" 


Y 


"id" and 

"header" 

and "user" 


Absent 


Addr-spec is the 
default public user 
identity 


"unavailable@unknown. invalid" 


N/Y 
(see note 2) 


If present: 
"id" and 
"header" 

and "user" 


Allowed 


Addr-spec: calling 
party number address 
signal is matched with 
one of the public user 
identities else if no 
matched the default 
public user identity is 
used (see note 1) 


Addr-spec is derived from Calling 
Party Number parameter Address 
Signals (see note 1) 


Y 


"none" 


NOTE 1 : Mapping CLI parameters to SIP header fields see table 5.2.3.2-3. 

NOTE 2: As network option. 

NOTE 3: Calling party number available but number digits are not included. 
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Table 5.2.3.2-3: Mapping CLI parameters to SIP header fields at the Gm interface 



SETUPS 


INVITE^ 


Calling party number IE 


From Header Field 


P-Preferred-ldentity 


Type of number 


Numbering plan 
identification 






No or invalid (see note 1) 
calling party number 
information element 


See table 5.2.3.2-1 


See table 5.2.3.2-1 


National number 


ISDN/telephony 
numbering plan 
or 
Unknown 


The userinfo is derived from 
the address string of the 
calling party number IE 
sip: local-number-digits; 
phone- 

context=xxxxxx@hostporti 

on; user=phone 

(see note 2) 


An attempt is made to match 
the address string of the calling 
party number IE to one of the 
calling party's registered public 
identities. If no match is 
determined, a default 
registered public identity is 
used. 


International 
number 


The userinfo is derived from 
the address string of the 
calling party number IE 

sip: global-number-digits 
@hostportion; 

user=phone 


The userinfo is derived from 
the address string of the calling 
party number IE 
sip: global-number-digits 

@hostportion; 
user=phone 


Subscriber 


The userinfo is derived from 
the address string of the 
calling party number IE 
sip: local-number-digits; 
phone- 

context=xxxxxx@hostporti 

on; user=phone 

(see note 2) 


An attempt is made to match 
the address string of the calling 
party number IE to one of the 
calling party's registered public 
identities. If no match is 
determined, a default 
registered public identity is 
used. 


Unknown 


The userinfo is derived from 
the address string of the 
calling party number IE 

sip: local-number-digits; 
phone- 

context=xxxxxx@hostporti 

on; user=phone 

(see note 2) 


An attempt is made to match 
the address string of the calling 
party number IE to one of the 
calling party's registered public 
identities. If no match is 
determined, a default 
registered public identity is 
used. 


NOTE 1 : Validity conditions of the calling party number information element are defined in 3.5.2.2. 1/Q. 951 [30]. 
NOTE 2: The combination of dialled digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 
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Table 5.2.3.2-4: Mapping CLI parameters to SIP header fields at the Mw interface 



SETUPS 


INVITE^ 


Calling party number IE 


From Header Field 


Type of number 


Numbering plan 
identification 




No or invalid (see note 1) 
calling party number 
information element 


See table 5.2.3.2-2 


National number 


ISDN/telephony 
numbering plan 
or 
Unknown 


The userinfo is derived from the address string of the calling 
party number IE 

sip: local-number-digits; phone-context=xxxxxx@hostportion; 
user=phone (see note 3) 


International 
number 


The userinfo is derived from the address string of the calling 

party number IE 

sip: global-number-digits @hostportion; user=phone 


Subscriber 


The userinfo is derived from the address string of the calling 
party number IE 

sip: local-number-digits; phone-context=xxxxxx @hostportion; 
user=phone (see note 3) 


Unknown 


The userinfo is derived from the address string of the calling 
party number IE 

sip: local-number-digits; phone-context=xxxxxx@hostportion; 
user=phone (see note 3) 


NOTE 1 : Validity conditions of the calling party number information element are defined in 3.5.2.2. 1/Q. 951 [30]. 

NOTE 2: When the AGCF receives an SETUP with a Calling party number that matches one of the registered 
public user identities, the AGCF will insert this public user identity in the P-Asserted-ldentity as a result 
of applying the procedures defined for a UE and the P-CSCF. When the AGCF receives an SETUP with 
a Calling party number that does not match one of the registered public user identities, or the SETUP 
does not contain a Calling party number, the AGCF will insert the registered public user identity in the 
P-Asserted-ldentity header. 

NOTE 3: The combination of dialled digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 



5.2.4 Conference calling (CONF) 

This service is for further study. 

5.2.5 Communication Diversion Services (CDIV) 

As a network option the Activation, Deactivation and Interrogation of call forwarding services is performed using 
service code commands as described in EN 300 207-1 [34] (ISDN; Diversion supplementary services) and 
EN 300 196-1 [25] (ISDN; Generic functional protocol for the support of supplementary services). 

NOTE: These messages are mapped to the regarding PSTN XML documents described in clause 4.9 of 
TS 183 004 [8] and are sent via the Ut-interface to the AS. 

5.2.5.1 Actions at the Outgoing AGCF/VGW 

5.2.5.1 .1 Reception of a "call is diverting" notification 

According to TS 183 004 [8], the 181 Being Forwarded may be received. 

5.2.5.1.1.1 First diversion 

The latest history-entry, representing the diverted-to-number, contained in the History-Info header is stored. 
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A notification of diversion is sent to the calling user as shown in table 5.2.5.1.1.1-1. 

Table 5.2.5.1.1.1-1: First diversion: notification of diversion sent to the calling user 



<-DSS 1 message 
(see note) 


<-181 (Call Being Forwarded) 




Notification indicator 
Information element 




Call is diverting 




NOTE: If no message is to be sent, the notification indicator information element is sent in a NOTIFY message. 



5.2.5.1.1.2 Subsequent diversion 

The latest history-entry, represents the diverted-to-number, contained in the History-info header field is stored if tlie 
URI of tlie liistory-entry is different to tlie previous received and stored diverted-to number (i.e. the latest received 
diverted-to number replaces the one received previously). 

If notification of diversion is not allowed, no specific interworking action is required towards the calling user. 

If notification of diversion is allowed, table 5.2.5.1.2-1 is applicable. 

Table 5.2.5.1.1.2-1 : Subsequent diversion: notification of diversion sent to the calling user 



<-DSS 1 message 
(see note 1 ) 


<-181 Call Being Forwarded 




Notification Indicator IE 


No notification sent 


History-Info header: latest history-entry 


Call is diverting 


cause=487 (Deflection during alerting) 

or 

cause=408 (No reply) 


No notification sent 


Other cause values 


NOTE 1 : The determination of the DSS 1 message sent upon 181 Being Forwarded is described in clause 5.1 . If no 

message is to be sent, the notification indicator information element is sent in a NOTIFY message. 
NOTE 2: The latest received diverted-to number replaces the one received previously. 



5.2.5.1 .2 Evaluation of History-Info header 

If a backward message (provisional response or 200 OK) is received containing a History-Info header and there is no 
privacy header is included in the URI of the latest history-entry: 

• it has been determined, according to TS 183 004 [8], that the notification of diverted-to number is allowed, a 
redirection number information element is sent to the calling user as shown in 

table 5.2.5.1.2-1; 

• if a Privacy=history is included in the latest history-entry, no information is sent to the calling user. 
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Table 5.2.5.1.2-1 : Notification of thie diverted-to number 



<-DSS 1 message (see note 1) 


Redirection number parameter 
stored in ttie originating entity 


^181, 180 or 200 OK 


Redirection number 
information element 


History-Info header: 
Latest History-entry 


Type of number 

According to the nature of address 
indicator (see note 2) 
Numbering plan identification 
ISDN (telephony) numbering plan 
Presentation indicator 

Presentation allowed 
Number digits 
Digits received in the userinfo 


Nature of address indicator 

National number sip: local-number-digits; 

phone-context=nat @hostportion; 

user=phone 

International number s\p: global-number- 

digits@hostportion; 

user=phone. 

Numbering plan indicator 

ISDN (telephony) numbering plan 

Address signal: User portion received in 

the URI; if the country code of the URI: In 

case for global number and the country 

code is the same as the AGCF/VGW or line 

is located, the country code is removed 

from the number of the Type of number is 

set to "national number". 


Mw or Gm Interface 

No Privacy header included 


Type of number 

Unl<nown 

Numbering plan identification 

Unknown 

Presentation indicator 

Presentation restricted 
Number digits 
Not includedDigits 
or no Information Element is sent 


Nature of address indicator 

National number sip: local-number-digits; 

phone-context=nat @hostportion; 

user=phone 

International number s'\p: global-number- 

digits@hostportion; 

user=phone. 

Numbering plan indicator 

ISDN (telephony) numbering plan 

Address signal 

User portion received in the URI. In case for 

global number and the country code is the 

same as the AGCF/VGW or line is located, 

the country code is removed from the 

number of the Type of number is set to 

"national number" 


Mw Interface 

Privacy header Included and 
the value Is equal to 
"history" 


Type of number 

Unl<nown 
Numbering plan identification 

Unl<nown 
Presentation indicator 
Number not available due to 
interworking 
Number digits 

Not included 
(see note 3) 
or no Information Element is sent 


No redirection number stored 


Mw or Gm Interface 

No History-Info header 
received 


NOTE 1 : The determination of the DSS 1 message sent upon the SIP backward message is described in 

clause 5.1 . If no message is to be sent, the redirection number information element Is sent in a NOTIFY 
message. 

NOTE 2: As a network option, the type of number may be coded unknown. 

NOTE 3: This redirection number is sent if e 181 was received and no History-Info header was included in any 
response. 



5.2.5.1.3 



Procedures at the T reference point 



When the AGCF/VGW receives a SETUP containing a FaciHty information element including a 
DivertingLegInformation2 invoke component, an INVITE is sent containing a History-Info header. 
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Table 5.2.5.1.3-1 : Mapping of the DivertingLeglnformation2 
invoke component into thie l-iistory-lnfo header 



SETUP -^ 


INVITE ^ 


DivertingLeglnformation2 


History-Info header 


diversionCounter 


1 


History Index 
Number of diversions are 
sown due to the number 
of Index Entries 
(see note) 


Index for divertingNr = 1 
Index for Request URI = 1 .1 


2 


Index for originalCalledNr = 1 
Index for divertingNr =1.1 
Index for Request URI = 1.1.1 


N 


Index for originalCalledNr = 1 
Placeholder History entry with Index = 
1.1 

Fill up 

Index for divertingNr = 1 +[(N-1 )*".1 "] 

Index for Request URI 

= 1+N*".1"(e.g. N=3^ 1.1.1.1) 


diversionReason 


unl<nown 


Cause parameter in latest History entry 


"404" 


cfu 


"302" 


cfb 


"486" 


cfnr 


"408" 


cdAlerting 


"487" 


cdlmmediate 


"480" 


divertingNr 


2™ latest entry 


originalCalledNr 


first entry 


NOTE: The History index is generated acco 


'ding the rules in subclause 4 in RFC 4244 [45]. 



When the AGCF/VGW receives a 18x provisional or 200 OK final response, the AGCFA'GW sends a FACILITY, 
ALERTING or CONNECT message. The value of the Privacy parameter in the latest contained History-Info header is 
mapped in a DivertingLeglnformationS invoke component. A FACILITY is only sent, if the 181 contains a 
History-Info header. 

Table 5.2.5.1.3-2: IVIapping of the value of the Privacy parameter in latest History Entry 
into the DivertingLeglnformation2 invoke component 



<- DSS1 Message 


<- SIP Message 


DivertingLeglnformationS: 
presentationAllowedlndicator 


History-Info header: 

Privacy parameter in the latest History entry 


FACILITY 


true 


181 (Being Forwarded) 


No Privacy parameter 


false 


Privacy: "history" 


ALERTING 


true 


180 (Ringing) 


No Privacy parameter 


false 


Privacy: "history" 


CONNECT 


true 


200 OK (INVITE) 


No Privacy parameter 


false 


Privacy: "history" 



5.2.5.2 



Actions at the incoming AGCF/VGW 



5.2.5.2.1 



Interworking at the AGCF/VGW where a call is diverted within or beyond the 
private ISDN (T reference point) 



When the AGCF/VGW receives a DSSl PROGRESS or ALERTING message, a Provisional Response is sent. When a 
FACILITY message is received containing a DivertingLeglnformationl invoke component, a 181 Provisional Response 
is sent. 

If the DSSl FACILITY, PROGRESS or ALERTING message contains a DivertingLeglnformationl invoke component 
Information Element, a History-Info header is sent in concerned response. The mapping is described in table 5.2.5.2.1-1 
and table 5.2.5.2. 1-2. 
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Table 5.2.5.2.1-1: Interworking of DSS1 messages 



<- SIP Message 


<- DSS1 Message 


180 (Ringing) 


ALERTING 


181 (Being forwarded) 


FACILITY 


183 (Session Progress) 


PROGRESS 



Table 5.2.5.2.1-2: Mapping of the DivertingLeglnformationI invoke component 

into History-Info header 



<- SIP Message 18x 


^ ALERTING, FACILITY, PROGRESS 


History-Info header 


DivertingLeglnformationI 


Latest History Entry: 
cause-param = 
"cause" EQUAL 
Status-Code 


"404" 


diversionReason 


unknown 


"302" 


cfu 


"486" 


cfb 


"408" 


cfnr 


"487" 


cdAlerting 


"480" 


cdlmmediate 


Privacy parameter in 
the latest History Entry 




subscriptionOption 


noNotification 


"History" 


notificationWithoutDivertedToNr 


No Privacy parameter 


notificationWithDivertedToNr 


latest Hi-targeted-to URI 


divertedToNumber 



If the DivertingLeglnformationI invoke component: subscriptionOption is coded noNotification, no 
History-Info header is sent in the response message. For the same circumstance, a FACILITY message is not 
interworked. 

In addition, if the ALERTING, FACILITY or CONNECT message contains a DivertingLeglnformationS invoke 
component. The Privacy parameter escaped in the Hi-target-to-uri representing the diverted-to user in the History-Info 
header (last entry) is set to the value as described in table 5.2.5.2.1-3. 

Table 5.2.5.2.1-3: Mapping of the value of the Privacy parameter in latest History Entry 
into the DivertingLeglnformationS invoke component 



<- SIP Message 


<- DSS1 Message 


History-Info header: Privacy parameter in the latest 
History entry 


DivertingLeglnformationS: presentationAllowedlndicator 


180 (Ringing) 


No Privacy parameter 


ALERTING 


true 


Privacy: "history" 


false 


181 (Being forwarded) 


No Privacy parameter 


FACILITY 


true 


Privacy: "history" 


false 


200 OK (INVITE) 


No Privacy parameter 


CONNECT 


true 


Privacy: "history" 


false 



5.2.5.2.2 Interworking at the coincident S and T reference point where a diverted call is 

presented 

Table 5.2.5.2.2-1 : Redirecting number information element sent to the called user 



INVITE^ 


SETUPS 


History-Info header 


Content 


index = 1.1 


Redirecting number information element 
(see table 5.2.5.2.2-2) 


index > 1.1 


1^' Redirecting number information element 
(see table 5.2.5.2.2-2) 

2"^* Redirecting number information element 
(see table 5.2.5.2.2-3) 
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Table 5.2.5.2.2-2: Coding of the first Redirecting number information element 



History-info header 


Redirecting number 


first entry; index=1 


information element 


No Privacy header included 


Type of number (see notes 1 and 5) 
Numbering plan identification (see notes 2 
and 5) 

Presentation indicator: presentation allowed 
Reason of diversion: (see note 3) 
Number digits: (see notes 4 and 5) 


Privacy=liistory included 


Type of number: unknown 

Numbering plan identification: unknown 

Presentation indicator: presentation 

restricted 

Reason of diversion: (see note 3) 

No Number digits 


First entry not included 


Type of number: unknown 

Numbering plan identification: unknown 

Presentation indicator: number not available 

due to interworking 
Reason of diversion: (see note 3) 
No Number digits 


NOTE 1 : National if the URI is coded as follows sip: local-number-digits; phone-context=nat 

@hostportion; user=phone or 

intemationar\f the URI is coded as follows sip: global -number-digits @hostportion; 

user=phone. 
NOTE 2: ISDN numbering plan. 
NOTE 3: If the index of the latest history-entry is set to 1 .1 : as received in the cause parameter in 

the latest history-entry. 

If the index of the latest history-entry is greater than 1 .1 : unknown. 
NOTE 4: User portion as received in the second last URI; global-number-digits: if the country 

code of the URI is the same as the country where the user or line is located, the country 

code is removed from the user portion. 
NOTE 5: As a network provider option the prefix is added to the number. In this case the 

Numbering plan identification and the Type of number are coded unknown. 
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Table 5.2.5.2.2-3: Coding of the second Redirecting number information element (if any) 



History-Info header 


Redirecting number 


second last history-entry 


information element 


No Privacy lieader included 


Type of number (see notes 1 and 5) 
Numbering plan identification (see notes 2 
and 5) 

Presentation indicator: presentation allowed 
Reason of diversion: (see note 3) 
Number digits: (see notes 4 and 5) 


Privacy=history included 


Type of number: unknown 

Numbering plan identification: unknown 

Presentation indicator: presentation 

restricted 

Reason of diversion: (see note 3) 

No Number digits 


First entry not included 


Type of number: unknown 

Numbering plan identification: unknown 

Presentation indicator: number not available 

due to interworking 
Reason of diversion: (see note 3) 
No Number digits 


NOTE 1 : -National if the URI is coded as follows sip: local-number-digits; phone-context=nat 

@hostportion; user=phone or 

- international \i the URI is coded as follows sip: global -number-digits @hostportion; 

user=phone. 
NOTE 2 : ISDN numbering plan. 

NOTE 3: As received in the cause parameter of the index of the latest history-entry. 
NOTE 4: User portion as received in the second last URI; global-number-digits: if the country 

code of the URI is the same as the country where the user or line is located, the country 

code is removed from the user portion. 
NOTE 5: As a network provider option the prefix is added to the number. In this case the 

Numbering plan identification and the Type of number are coded unknown. 



5.2.5.2.3 



Table 5.2.5.2.2-4: IVIapping of cause parameter in the history-entry 
to reason of diversion 



Cause parameter 


Reason of diversion 


unl<nown 


"404" 


Unl<nown 


unconditional 


"302 " 


Call forwarding unconditional 


User Busy 


"486" 


Call forwarding busy 


No reply 


"408" 


Call forwarding no reply 


Deflection during alerting 


"487" 


Call deflection during alerting 


Deflection immediate response 


"480" 


Call deflection immediate response 


Mobile subscriber not reachable 


"503" 


Unl<nown 



Interworking at the AGCF/VGW where a diverted call is presented to a private 
ISDN (T Reference point) 



When the AGCF/VGW receives an INVITE, a SETUP is sent on the network/user interface. If the INVITE contains a 
History-Info header, the History-Info header is mapped into a DivertingLegInformation2 invoice component. The 
History-Info header is stored in the AGCFA'GW. 
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Table 5.2.5.2.3-1 : Mapping of the History-Info header into the 
DivertingLeglnformation2 invoke component 



INVITE ^ 


SETUP -^ 


History-Info header 


Diverting Leglnformatlon2 


The number of dots in tlie latest index value represents the 
diversionCounter value 


diversionCounter 


cause-param = "cause" 
EQUAL Status-Code in 
latest History entry 


"404" 


diversionReason 


unknown 


"302" 


cfu 


"486" 


cfb 


"408" 


cfnr 


"487" 


cdAlerting 


"480" 


cdlmmediate 


2™ latest entry 


divertingNr 


first entry 


originalCalledNr (see note) 


NOTE: This element is not sent, if the diversionCounter is sent with the value 1 . 



As a response to this call setup, three possibilities are applicable: 

a) No further diversion occurs 

When a ALERTING, PROGRESS or CONNECT is received, the messages are interworked on a basic call 
base. The stored History-Info header received in the previous received INVITE is included in the Provisional 
Response or 200 OK INVITE. A Privacy parameter with value "history" is escaped in the last entry 
representing the diverted to user. 

b) A call diversion in the private network 

When a ALERTING, PROGRESS or FACILITY is received containing a DivertingLeglnformationl invoke 
component, the stored History-Info header received in the previous received INVITE is included in the 
Provisional Response and a history entry shall be added, interworked from the received 
DivertingLeglnformationL The sent History-Info header is stored in the AGCF/VGW, the previous stored 
History-Info header is overwritten. 

Table 5.2.5.2.3-2: lUlapping of the DivertingLeglnformationl 
invoke component into added history entry 



<- SIP Message 18x 


<- ALERTING, FACILITY, PROGRESS 


History-Info header 


DivertingLeglnformationl 


Added (latest) History 
Entry: cause-param = 
"cause" EQUAL 
Status-Code 


"404" 


diversionReason 


unknown 


"302" 


cfu 


"486" 


cfb 


"408" 


cfnr 


"487" 


cdAlerting 


"480" 


cdlmmediate 


Privacy parameter in 
the added (latest) 
History Entry 




subscriptionQption 


noNotification 


"History" 


notificationWithoutDivertedToNr 


No Privacy parameter 


notificationWithDivertedToNr 


Added (latest) Hi-targeted-to URI 


divertedToNumber 



If the DivertingLeglnformationl invoke component: subscriptionOption is coded noNotification, no History-Info 
header is sent in the response message. For the same circumstance, a FACILITY message is not interworked. 

c) A further call diversion beyond the private network 

In addition, if the ALERTING, FACILITY or CONNECT message contains a DivertingLegInformation3 
invoke component. The Privacy parameter escaped in the Hi-target-to-uri representing the diverted-to user in 
the History-Info header (last entry) is set to the value as described in table 5.2.5.2.1-3. 
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5.2.5.2.4 Interworking at the AGCF/VGW where partial rerouting is requested from a 

private ISDN (T Reference point) 

After the INVITE was sent, when a FACILITY containing the CallRerouteing invoke component is received, a 
302 (Moved Temporarily) is sent. The called Address element of the CallRerouteing invoke component is mapped 
into the URI of the Contact header. If the CallRerouteing invoke component: subscriptionOption is coded 
noNotification, no History-Info header is sent in the 302 response message. 

Table 5.2.5.2.4-1 : Mapping of the CallRerouteing invoke component 
into 302 (Moved Temporarily) 



<- 302 (Moved Temporarily) 


^ FACILITY 




CallRerouteing invoke component 


History-Info header: 
Last History Entry: 
cause-param = "cause" 
EQUAL Status-Code 


"404" 


rerouteingReason 


unknown 


"302" 


cfu 


"486" 


cfb 


"408" 


cfnr 


"487" 


cdAlerting 


"480" 


cdlmmediate 


Contact header 


URI 


calledAddress 


History-Info header: 
History Index 
Number of diversions 
are sown due to the 
number of Index Entries 
(see note) 


Index for lastRerouteingNr 

= 1 

Index for calledAddress = 

1.1 


rerouteingCounter 


1 


Index for To header = 1 

Index for lastRerouteingNr 

URI = 1.1 

Index for calledAddress = 

1.1.1 


2 


Index for To header = 1 
Placeholder History entry 
with Index = 1.1 

Fill up 

Index for lastRerouteingNr 
URI = 1+[(N-1)*".1"] 
Index for calledAddress 
= 1+N*".1"(e.g. N=3^ 
1.1.1.1) 


N 


PSTN XML body 


BearerCapability 


q931lnfoElement 


Bearer Capability 


LowLayerCompatibility 




Low layer compatibility 


HighLayerCompatibility 




High layer compatibility 


User-to-User header 




User-user information 


History-Info header: 2™ latest entry 


lastRerouteingNr 


History-Info header: 
Privacy parameter in 
the last History Entry 


No History-Info header 


subscriptionOption 


noNotification 


"History" 




notificationWithoutDivertedToNr 


No Privacy parameter 




notificationWithDivertedToNr 


No mapping (see note) 


callingPartySubaddress 


NOTE: The calling subaddress is contained in the From header of the original INVITE. 



NOTE: Appropriate handling of the mapped information in the 302 have to be described in the PSTN/ISDN 
simulation service specification TS 183 004 [8] Communication diversion service. The History-Info 
header contained in the 302 is not used. Currently only the calledAddress in the Contact header is used. 

5.2.6 MCID 

5.2.6.1 Actions at the Outgoing AGCF/VGW 

There is no interworking requirement relating to the Malicious Call Identification (MCID) supplementary service. 
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5.2.6.2 Actions at the incoming AGCF/VGW 

There is no interworking requirement relating to the MaHcious Call Identification (MCID) supplementary service. 

Invocation of the service 

To invoke the MCID supplementary service, the called user shall send a McidRequest invoke component carried by a 
Facility information element in a FACILITY message. This invocation can only be sent during the Active state (NIO), 
during the Disconnect Indication state (N12) the invocation is not successful. 

To indicate that the service invocation has been accepted, the network shall send a McidRequest return result 
component carried by a Facility information element in a FACILITY message. 

These messages are mapped to a relNVITE as described in clause 4.5.2.12.1 of TS 183 016 [46] and are sent to the AS. 

Table 5.2.6.2-1 : MCID request 



<- INVITE 


<- FACILITY 


XML mcid 
request 

McidRequestlndicator="1 " (network 
operator option) 


McidRequest 



Additionaly as an option to invoke the MCID service, as a network option it is possible to use service code commands 
via in-band dialogue or using the service code via keypad protocol. These requirements to using the keypad protocol are 
described in annex A of the present document. The result is available in-band (announcement). 

5.2.7 Explicit Communication Transfer (ECT) 
5.2.7.1 Actions at the Outgoing AGCF/VGW 

For this service, the separation "incoming call" and "outgoing call" does not apply. 

This clause describes the interworking at the AGCF/VGW (i.e. the exchange where the served user is connected to). To 
simulate ECT in the IMS, the Consultative Transfer is applicable. 



5.2.7.1.1 



Coincident S and T reference point 



5.2.7.1 .1 .1 Service invocation 

The invocation of ECT in the alerting state should be rejected by the AGCFA'^GW. 

Table 5.2.7.1.1.1-1: ECT invocation 



Message received 
from the served user (user A) 


REFER 


FACILITY^ 

Facility information element 

EctExecute invoke component 

or 

ExplicitEctExecute invoke 

component 


The request URI shall contain the SIP URI of the transferee as 
received in the Contact header field 

The Refer-To header field shall indicate the public address of the 

transfer Target. 

A Replaces header field parameter shall be added to the Refer-To 

URI together with a Require=replaces header field parameter. 

Method=INVITE 



The ECT procedures are performed by the Application Server and described in TS 183 029 [36] As a network provider 
option: The REFER may be interworked in a relNVITE to the Transferee and to the Transfer target. These special 
REFER handling procedures are described in the TS 183 028 [32]. 
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5.2.7 A .2 T reference point 

5.2.7.1.2.1 Service invocation 

Receipt of a notification from the access: 

Table 5.2.7.1.2.1-1 : Receipt of a notification from thie access 



Message received from the access 




FACILITY^ 

Facility information element 




Ectlnform invoke component 
alerting 


No mapping 


FACILITY^ 

Facility information element 

Ectlnform invoke component 

active 

redirectionNumber (see note) 




Facility information element (see note) 
SubaddressTransfer invoke component 


No mapping 


NOTE: The Access transport parameter is not interworked sent if the 
SubaddressTransfer invoke component is received. 



5.2.7.2 Actions at the incoming AGCF/VGW 

For this service, the separation "outgoing call" and "incoming call" does not apply. 

This clause describes the interworking at the O/I-AGCF/VGW (i.e. the AGCFA/^GW where the remote user(s) is(are) 
connected to). 

5.2.7.2.1 Coincident S and T reference point 

5.2.7.2.1.1 Messages received from the network 

5.2.7.2.1 .1 .1 Receipt of an INVITE/UPDATE message 

The ECT simulation service is performed as described in TS 183 029 [36] with the additions and clarifications 
described in TS 183 028 [32] in special REFER handling procedures. 

Upon receipt of an INVITE or UPDATE: 

a) relNVITE the corresponding remote ECT user is in alerting state 

NOTE: This interworking is applicable to the user in "active call state, call held auxiliary state" when the 
corresponding remote ECT user is in alerting state. 

Table 5.2.7.2.1.1.1-1: INVITE/UPDATE 



Message received from the 




network 






INVITE -^ 


No mapping 


No mapping 


NOTE: This can only occur in case of interaction of ECT with ECT. 
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b) relNVITE the corresponding remote ECT user is in answered state 

NOTE: This interworking is appHcable to the user in "active call state, call held auxiliary state" or "active call 
state, idle auxiliary state" or "call delivered state" when the corresponding remote ECT user is in 
answered state. 

Table 5.2.7.2.1.1.1-2: INVITE/UPDATE 



INVITE -^ 




INVITE 


P-Asserted-ldentity 
Privacy absent or not "id" 

Connected Subaddress 
information element as isub 
parameter in the P-Asserted- 
ldentity 


No mapping 




Other cases 
(see note 2) 


No mapping 


NOTE 1 : This can only occur in case of interaction of ECT with ECT. 
NOTE 2: Other cases: 

- no subaddress in the relNVITE; or 

- Privacy header value "id"; or 

- no P-Asserted-ldentity in the relNVITE. 



Table 5.2.7.2.1.1.1-3: INVITE/UPDATE 



INVITE/UPDATE not completing 
a 




Call transfer, alerting 
notification 






INVITE/UPDATE ^ 
P-Asserted-ldentity (see note 2) 


No mapping 


No mapping 


NOTE 1 : This can only occur in case of interaction of ECT with ECT. 
NOTE 2: The P-Asserted-ldentity may be absent. 



5.2.7.2.1 .1 .2 Receipt of a UPDATE message for a call in alerting phase 

This clause applies only for a call in alerting phase. 
One case is possible: 
• UPDATE. 
UPDATE 
Upon receipt of such a message, one case is possible: 
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Table 5.2.7. 2A .1 .2-1 : UPDATE 



UPDATE -^ 






P-Asserted-ldentity, Privacy 
header absent or not "id". 

Connected Subaddress 
information element as isub 
parameter in the P-Asserted- 
ldentity 


No mapping 




Other cases 
(see note 2) 


No mapping 


NOTE 1 : This can only occur in case of interaction of ECT with ECT. 
NOTE 2: Other cases: 

- no subaddress in the UPDATE; or 

- Privacy header value "id"; or 

- no P-Asserted-ldentity present in the UPDATE. 



Table 5.2.7.2.1.1.2-2: UPDATE 



UPDATE not completing a 
ca//-fransfer-a/ert/ngf notification 




UPDATE^ 
P-Asserted-ldentity 


No mapping 



5.2.7.2.2 
5.2.7.2.2.1 



T reference point 

Service invocation: Messages received from the network 



5.2.7.2.2.1 .1 Receipt of an INVITE/UPDATE 

Upon receipt of an INVITE or UPDATE, two cases are possible: 

a) INVITE the corresponding remote ECT user is in alerting state 

NOTE 1: This interworking is applicable to the user in "active call state, call held auxiliary state" when the 
corresponding remote ECT user is in alerting state. 

b) INVITE the corresponding remote ECT user is in answered state 

NOTE 2: This interworking is applicable to the user in "active call state, call held auxiliary state" or "active call 
state, idle auxiliary state" or "call delivered state" when the corresponding remote ECT user is in 
answered state. 
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Table 5.2.7.2.2.1.1-1: INVITE/UPDATE 



INVITE/UPDATE ^ 






P-Asserted-ldentity 

Privacy header absent or value is 

not "id" 

Connected Subaddress 
information element as isub 
parameter in the P-Asserted- 
ldentity 


No mapping 




Other cases 
(see note) 


No mapping 


NOTE: Other cases: 

- no subaddress in the relNVITE; or 

- Privacy header value "id"; or 

- no P-Asserted-ldentity present in the relNVITE. 



5.2.7.2.2.1.2 
One case is possible: 
• UPDATE. 
a) UPDATE 



Receipt of a UPDATE for a call in alerting phase 



Table 5.2.7.2.2.1.2-1: UPDATE 



UPDATE -^ 






P-Asserted-ldentity, Privacy 
header absent or value not "id" 

Connected Subaddress 
information element as isub 
parameter in the P-Asserted- 
ldentity 


No mapping 




Other cases 
(see note) 


No mapping 


NOTE: Other cases: 

- No subaddress in the UPDATE; or 

- Privacy header value "id"; or 

- No P-Asserted-ldentity present in the UPDATE. 



5.2.8 Subaddressing (SUB) 



The Sub-address (SUB) service allows the called (served) user to expand his addressing capacity beyond the one given 
by the E.164 user number. Subaddressing (SUB). 

The coding rules according RFC 3966 [47] are not supporting the Type of subaddress (NS AP and user specified) as 
defined in ISDN (Q.931 [54]). Only the NSAP Type is mapped. 

The called party subaddress information element received from the access in the SETUP message is transported in the 
in the isub parameter of the To header of the INVITE (see RFC 3966 [47]). 
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5.2.8.1 



Actions at the Outgoing AGCF/VGW 

Table 5.2.8.1-1 : SIP Header information for subaddressing mapping 
at the l-AGCF/VGW contained in the INVITE 



SETUP ^ 


INVITE -^ 


Called party sub-address (NSAP) 


To header isub parameter 

Called party subaddress address string 


Calling party sub-address (NSAP) 


From header isub parameter 

Calling party subaddress address string 


NOTE: The subaddress with Type of subaddress "User specified" is not transferred. 



Table 5.2.8.1-2: SIP Header information for subaddressing mapping 
at the l-AGCF/VGW contained in the 200 OK INVITE 



^ CONNECT 


^ UPDATE 


Connected party sub-address (NSAP) 


From header isub parameter 
Connected subaddress address string 


NOTE: The subaddress with Type of subaddress "User specified" is not transferred. 



5.2.8.2 



Actions at the incoming AGCF/VGW 



The called party subaddress information element received in the isub parameter of the To header of the INVITE (see 
RFC 3966 [47]) is transferred transparently in the SETUP message. The number type value is a network option, NSAP 
is recommended. 

Table 5.2.8.2-1 : Sending of the called party subaddress (SUB) 



INVITE^ 


SETUPS 


To header Isub parameter 


Content 


Called party subaddress address string 


Called party subaddress information element 


NOTE: The number type "NSAP" is recommended; other value is a network option. 



Table 5.2.8.2-2: Sending of the calling party subaddress (SUB) 



INVITE^ 


SETUPS 


From header Isub parameter 


Content 


Calling party subaddress address string 


Calling party subaddress information element 


NOTE: The number type "NSAP" is recommended; other value is a network option. 



Table 5.2.8.2-3: receiving of the connected subaddress (SUB) 



<- UPDATE 


<- CONNECT 


From isub parameter 


Content 


Connected party subaddress address string 


Connected party subaddress information element 


NOTE: The number type "NSAP" is recommended; other value is a network option. 



5.2.9 Closed User Group (CUG) 



A XML element containing the identification of the closed user group transferred in the INVITE between two AS is 
described in the clause 4.9.2 of TS 183 054 [28]. 



5.2.9.1 



Actions at the Outgoing AGCF/VGW 



CUG checks at the originating Application Server and determination of the type of call request in correlation with the 
CUG information received from the calling user in the SETUP message and the CUG attributes of the calling user are 
described in table 4, ETS 300 138-1 [21]. 
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Invocation of Closed User Group 

Table 5.2.9.1-1 : Invocation of Closed User Group 



SETUPS 


INVITE^ 


Facility CUGCallOperation invoke 


XMLcug 

cugCallOperation 


outgoingAccessRequest 


outgoingAccessRequest 


cUGIndex 


cuglndex 



A rejection indication may be received in a 500 Server Internal Error. 

Table 5.2.9.1-2: Receipt of a rejection indication 



^-DISCONNECT 


<r- Final Response 


Cause Information element 


Return error component 


Response code 


Implicit request: 
Cause value No. 29 
Facility rejected 
Explicit request: 

Cause value No. 29 
Facility rejected 


No return error component 

Return error value #19 
incomingCallsBarredWithinCUG 


603 


Implicit request or not CUG request: 
Cause value No. 87 
User not member of CUG 
Explicit request: 
Cause value No. 29 
Facility rejected 


No return error component 

Return error value #20 
userNotlVlemberOfCUG 


403 


Implicit request: 

Normal handling of the cause value 

See 5.1 

Explicit request: 

Normal handling of the cause value 

See 5.1 


No return error component 

Return error value #8 
basicServiceNotProvided 


Other Response code 


NOTE: The above table provides examples of mapping. Another example of mapping is described in 
ETS 300 138-1 [21], annexe. 



5.2.9.2 



Actions at the incoming AGCF/VGW 



CUG checks at the destination Application Server and determination of the type of call request in correlation with the 
CUG information received in the Initial INVITE message and the CUG attributes of the called user are described in 
TS 183 054 [28]. The call setup sent to the CUG terminating user does not contain any CUG information. 

5.2.1 User User Service (UUS) 

The coding of the User-user information element is described within ETS 300 286-1 [38]. The User-to-User header is 
defined within draft-johnston- sipping-cc-uui-02.txt [i.l]. 

The content of the uuidata field of the User-to-User header shall start with the first octet being the protocol 
discriminator and followed by the user information octets. 

The format of the uuidata field shall be the hexadecimal representation of binary data coded in ascii alphanumeric 
characters. For example, the 8- bit binary value 001 1- 1111 is 3F in hexadecimal. To code this in ascii, one 8- bit byte 
containing the ascii code for the character '3' (001 1- 001 1 or 033H) and one 8- bit byte containing the ascii code for the 
character 'F' (0100- 01 10 or 046H) are required. For each byte value, the high-order hexadecimal digit is always the first 
digit of the pair of hexadecimal digits. The ascii letters used for the hex digits shall always be capital form. 

EXAMPLE: 

User-to-User: 04C81031313232333334343535363637373838FA08303900064630E9E0;encoding=hex. 
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Interworking procedures between the User-USer information element and User-to-User header are defined in the 
following clauses. 

5.2.1 0.1 Actions at the Outgoing AGCF/VGW 



5.2.10.1.1 



Service 1 (UUS1) implicit 



Service 1 may be requested implicitly by the presence of the user-user information element in the SETUP message 
which is mapped into the user-to-user information parameter of the initial INVITE. 

Table 5.2.10.1.1-1: Implicit UUS1 transfer 



DSS 1 messages 


SIP messages 


SETUP ^ 


INVITE -^ 


User-user information element 

Protocol discriminator and User Information 


User-to-User header 
uuidata 


PROGRESS, ALERTING, CONNECT, DISCONNECT ^ 


18x, 200OK, BYE^ 


User-user information element 

Protocol discriminator and User Information 


User-to-User header 
uuidata 


DISCONNECT, RELEASE, RELEASE COMPLETE ^ 


BYE^ 


User-user information element 

Protocol discriminator and User Information 


User-to-User header 
uuidata 



5.2.10.1.2 



Service 1 (UUS1) explicit 



Table 5.2.1 0.1 .2-1: Explicit UUS1 invocation 



SETUPS 



Content 



Facility information element 

UserUserService invoke component 
Service 1 preferred 



User-user information element 



Facility information element 

UserUserService invoke component 
Service 1 required 



User-user information element 



A service 1 explicit request preferred or required is rejected as described below. 

Service 1 rejection 

Rejection initiated by the O-AGCF/VGW when it cannot support the service is not relevant to the interworking and is 
described in clause 9.1.1.2.2/EN 300 286-1 [38]. 



Table 5.2.10.1.2-2 describes the handling of a rejection indication received from the network when the service 1 was 
requested as required. 



Table 5.2.10.1.2-3 describes the handling of a rejection indication received from the network when the service 1 was 
requested as preferred. 

Table 5.2.10.1.2-2: Service 1 rejection service requested as "required" 



DSS1 messages 


SIP messages 


^-DISCONNECT 




Cause information element 
Value 69 (requested facility not impiemented 
Facility information element 
UserUserService return error component 
reJectedByNetworl< 
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Table 5.2.10.1.2-3: UUS1 rejection: service requested as "preferred" 



DSS 1 messages 


SIP messages 


CALL PROCEEDING, ALERTING, PROGRESS, 
CONNECT, DISCONNECT or RELEASE 

<- 




Facility information element 

UserUserService return error component 
rejectedByNetwork 


NOTE: UUS return error component shall be sent in next regular message. 



5.2.10.1.3 



Service 2 



Table 5.2.10.1.3-1: UUS2 invocation 



SETUPS 


SIP messages 


Content 




Facility information element 

UserUserService invoke component 
Service 2 preferred 


Facility information element 

UserUserService invoke component 
Service 2 required 



A service 2 is rejected as described below: 

Service 2 rejection 

Rejection initiated by the O-AGCF/VGW when it cannot support the service is not relevant to the interworking and is 
described in clause 9.2.1.2/ EN 300 286-1 [38]. 



Table 5.2.10.1.3-2 describes the handling of a rejection indication received from the network when the service 2 was 
requested as required. 



Table 5.2.10.1.3-3 describes the handling of a rejection indication received from the network when the service 2 was 
requested as preferred. 

Table 5.2.10.1.3-2: UUS2 rejection: service requested as "required" 



DSS1 messages 


SIP messages 


^DISCONNECT 




Cause information element 
Value 69 (requested facility not implemented) 
Facility information element 
UserUserService return error component 
rejectedByNetwork 





Table 5.2.10.1.3-3: UUS2 rejection: service requested as "preferred" 



DSS 1 messages 


SIP messages 


^-ALERTING, DISCONNECT 




Facility information element 

UserUserService return error component 
rejectedByNetwork 
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5.2.10.1.4 



Service 3 



Table 5.2.10.1.4-1: UUS3 invocation 



SETUPS 


SIP messages 


Content 




Facility information element 

UserUserService invoke component 
Service 3 preferred 


Facility information element 

UserUserService invoke component 
Service 3 required 



A service 3 request during call setup is rejected as described below. 

Table 5.2.10.1.4-2: UUS3 activation received from the calling user in active phase 



FACILITY -^ 


SIP messages 


Facility information element 

UserUserService invoke component 
Service 3 preferred 





Service 3 rejection 

Rejection initiated by the O-AGCF/VGW when it cannot support the service is not relevant to the interworking and is 
described in clause 9.3.1.1.2/EN 300 286-1 [38]. 

Rejection of service 3 requested during call establishment. 



Table 5.2.10.1.4-3 describes the handling of a rejection indication received from the network when the service 3 was 
requested as required. 



Table 5.2.10.1.4-4 describes the handling of a rejection indication received from the network when the service 3 was 
requested as preferred. 

Table 5.2.10.1.4-3: UUS3 rejection: service requested as "required" during call establishment 



DSS1 messages 


SIP messages 


^DISCONNECT 




Cause information element 
Value 69 (requested facility not implemented) 
Facility information element 
UserUserService return error component 
rejectedByNetwork 



Table 5.2.10.1.4-4: UUS3 rejection: service requested 
as "preferred" during call establishment 



DSS 1 messages 


SIP messages 


^-CONNECT, DISCONNECT 




Facility information element 
UserUserService return error component 
rejectedByNetwork 



Rejection of service 3 requested after call establishment 

Rejection of service 3 requested after call establishment is not relevant to the interworking and is described in 
clause 9.3.1.2.2/EN 300 286-1 [38]. 
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Table 5.2.10.1.4-5: Rejection of UUS3 requested by the calling user after call establishment 



DSS 1 messages 


SIP messages 


<-FACILITY 




Facility information element 

UserUserService return error component 
rejectedByNetwork 



5.2.1 0.2 Actions at the incoming AGCF/VGW 



5.2.10.2.1 



Service 1 (UUS1) implicit 



Service 1 may be requested implicitly by the presence of the User-to-User header field of the Initial INVITE which is 
mapped into the user-user information element in the SETUP message. 



If service 1 is requested: 



Table 5.2.10.2.1-1 : Implicit UUS1 transfer 



SIP messages 


DSS 1 messages 


INVITE ^ 


SETUP ^ 


User-to-User header 
uuidata 


User-user information element 

Protocol discriminator and User Information 


18x, 200OK, BYE 
(see note) 

<- 


ALERTING, CONNECT, DISCONNECT, RELEASE, 
RELEASE COMPLETE 

<- 


User-to-User header 
uuidata 


User-user information element 

Protocol discriminator and User Information 


BYE 


DISCONNECT 


User-to-User header 
uuidata 


User-user information element 

Protocol discriminator and User Information 


NOTE: The correspondences between SIP and DSS 1 messages are described in clause 5.1 .1 . 



If there is no user-user information element in the SETUP message, the Application Server shall discard the User-to- 
User header field possibly received afterwards from the user or from the SIP side. 

5.2.11 Call Waiting (CW) 

5.2.1 1 .1 Actions at the Outgoing AGCF/VGW 

Table 5.2.1 1.1-1: Mapping of 18x provisional responses for CW procedure in ISDN access 



^ALERTING/PROGRESS/NOTIFY 
(see note) 


^18x 


Notification indicator information element 


Alert-Info: <urn:alert:service:call-walting> 


Notification description 




110 0000 
Call is a waiting call 




NOTE: The criteria of sending of ALERTING or PROGRESS is defined in clause 5.1 . If neither ALERTING 
or PROGRESS has to be sent, a NOTIFY message is sent. 



5.2.1 1 .2 Actions at the incoming AGCF/VGW 

5.2.1 1 .2.1 Procedure at coincident S and T reference point 

CW indication indicates the call waiting service is activated against the user. 
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AGCF/VGW uses this CW indication in conjunction with the B-channel busy condition, and if both apply, 
AGCF/VGW shall send SETUP with "no channel" in the information channel selection field of the Channel 
identification information element. 

If B-channel busy condition is not met, AGCFA'^GW should ignore the CW indication and send SETUP according to 

clause 5.1.2.1. 

If CW indication is not present, and B-Channel busy is detected, AGCF/VGW should reject the call with 486 (Busy 
Here). 

If CW indication is not present, and B-Channel busy is detected, AGCF/VGW should reject the call with 486 (Busy 
Here) or AGCF/VGW shall send SETUP with "no channel" in the information channel selection field of the Channel 
identification information element as an network option. 

Table 5.2.1 1.2.1-1: Receipt of CW indication 



INVITE^ 


SETUPS 

Channel identification information element 
information channel selection 


Content-Type: application/3gpp-ims+xml 
Content Disposition: 3gpp-alternative-service 
IVIIMEXML 

ims-3gpp version="1" 
alternative-service 
action 

call-waiting-indication 


No channel 



If the call is presented with indication no channel in the information channel selection field of the channel identification 
information element in the SETUP message, and depending on the subscription options offered by the network, a 
notification is contained in the Alert-Info header sent in the network upon receipt of the alerting message. 

Table 5.2.1 1.2.1-2: Sending of CW notification 



^180 


^-ALERTING 


Alert-Info: <urn:aiert:service:call-waiting> 



5.2.1 1 .2.2 Notification received at T reference point 

A CW notification may be received at T reference point in the ALERTING message. 

Table 5.2.1 1 .2.2-1 : Receipt of a CW notification from a private network 



^18x 
(see note) 


<-ALERTING/PROGRESS/NOTIFY 




Notification indicator 
information element 




Notification description 


Alert-Info: <urn:alert:service:call-waiting> 


110 0000 

Call is a waiting call 


NOTE: Incaseof receipt of ALERTING or PROGRESS, 180 or 183 is sent as described in clause 5.1.2.2. In 
case of receipt of NOTIFY, 1 83 is sent. 
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5.2.12 Terminal Portability (TP) 

5.2.1 2.1 Actions at the outgoing AGCF/VGW 

5.2.1 2.1 .1 Invocation at coincident S and T reference point 

Table 5.2.12.1.1-1 :TP invocation 



Message received from the DSS 1 -^ 


INVITE / UPDATE^ 


SUSPEND 


SDP: a=sendonly 


RESUME 


SDR: a=sendrecv 



The action taken on the access side upon receipt of SUSPEND and RESUME messages are described in 5.6/Q.931 [54] 
and figure A.6/Q.931 [54]. 

Upon the T307 expiry, a Release message (BYE or CANCEL) is sent with the cause value No. 102, recovery on timer 
expiry. No action is taken on the DSS 1 side. 

5.2.1 2.1 .2 Notification received at T reference point 

A TP notification may be received at T reference point from a point-to-point data link in the active phase of the call. 
Table 5.2.12.1.2-1 : Receipt of a TP notification from a private network 



NOTIFY^ 


INVITE/UPDATE -^ 


Notification indicator 
information element 




Notification description 




000 0000 
User suspended 


SDP: a=sendonly 


000 0001 
User resumed 


SDP: a=sendrecv 



5.2.1 2.2 Actions at the incoming AGCF/VGSN 

5.2.1 2.2.1 Invocation at coincident S and T reference point 



Table 5.2.12.2.1-1 : TP invocation 



^ INVITE /UPDATE 


Message received from the DSS 1 


SDP: a=sendonly 


SUSPEND 


SDP: a=sendrecv 


RESUME 



The actions taken on the access side upon receipt of the SUSPEND and RESUME messages are described in 
5.2.6/Q.931 [54] and figure A.6/Q.931 [54]. 

5.2.1 2.2.2 Notification received at T reference point 

A TP notification may be received at T reference point in the active phase of the call. 
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Table 5.2.12.2.2-1 : Receipt of a TP notification from a private networl< 



^ INVITE / UPDATE 


^NOTIFY 




Notification indicator 
information element 




Notification description 


SDP: a=sendonly 


000 0000 
User suspended 


SDP: a=sendrecv 


000 0001 
User resumed 



5.2.13 Three-party (3PTY) 



Based on local policy, the AGCF may subscribe for the conference event package on behalf of the ISDN participant 
after he is added to a three party. 

When the conference event package option is implemented, and one of the following events occurs at the AGCFA^GW: 

• A 200 OK is received as a response to an initial INVITE request originated by the AGCF/VGW, where the 
Contact header field contains an "isfocus" parameter; or 

• An ACK message is received which acknowledges a 200 OK response to the initial INVITE request, and the 
initial INVITE request is originated by the conferencing AS and contains an "isfocus" parameter in the Contact 
header field. 

Then the following steps shall be performed: 

1) A SUBSCRIBE request shall be created according to RFC 4575 [44]. 

2) The request URI is set to the Contact address of the conferencing AS. 

3) The P-Asserted-Identity header field, the From header field and the Privacy header field are set with the same 
value as: 

the P-Asserted-Identity header field, the From header field and the Privacy header field in the initial 
INVITE request originated by the AGCFF/VGW; or 

the P-Asserted-Identity header field, the To header field and the Privacy header field in a Ixx or 2xx 
response sent by the AGCF/VGW to the initial INVITE request from the conferencing AS. 

When a full type of notification is received a check is made of the content. If the changes with respect a previous 
version of the notification have not been sent on to the ISDN user for this session, the AGCFVGW shall do a DSSl 
interaction towards the ISDN user. If the changes with respect a previous version of the notification have been sent to 
the ISDN user for this session, the AGCFA^GW shall not do an DSSl interaction towards the ISDN user. 

When a partial notification is received then it is assumed that a value of a received notification has changed, so the 
AGCF/VGW shall do an DSSl interaction towards the ISDN user. 

5.2.13.1 Notification received from the network 

Table 5.2.13.1-1 : 3PTY notification 



<-NOTIFY 


<- INVITE 


Notification indicator 
information element 


<conference-info> 


Notification description 


<conference-state> 


100 0010 
Conference established 


<active>true< active/> 


100 0011 
Conference disconnected 


<active>false< active/> 


111 1001 
Remote liold 


SDP a=sendonly 
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5.2.1 3.2 Invocation at coincident S and T reference point 



Before a three way conversation can be established, one of two existing sessions is set on hold by sending a relNVITE 
with an a attribute set to sendonly in the SDP. To invoke a three party communication after receipt of the Begin3PTY 
invoke component, the AGCF/VGW shall send a an INVITE request with the conference factory URI for the three-way 
session towards the conference focus as described in TS 183 005 [9]. It is assumed, that based on an initial filter 
criterion, the conference AS is involved in the SIP signalling chain. It is assumed, that the conference application server 
is responsible for the notification "conference-established" etc. The previous basic call sessions are not released. 

Option A: 3PTY invoke by sending a REFER request to each participant. 

Table 5.2.13.2-1 : Three-party (3PTY) invoke using the REFER request 



Procedure 


■message received from served 


lUlessages sent to the Conference AS or remote 




user 


user 




-^ 


-^ 




FACILITY^ 


INVITE Request URI: <userCactive@domain.com> 




Facility IE 


SDP: a=sendonly 


Beginning the 3PTY 


Begin3PTY-lnv 






Call reference IE 


INVITE Request URI: conference factory URI 




Call reference of call A-B 


REFER Request URI: conference factory URI 
Refer-to: <userBonHold@domain.com> 
Method=invite 

REFER Request URI: conference factory URI 
Refer-to: <userCactive@domain.com> 
IVlethod=invite 



Option B: 3PTY invoke by sending an INVITE request with the conference factory URI for the three-way session 
towards the conference focus including the participant list containing the two 3PTY participants. 

Table 5.2.13.2-2: Three-party (3PTY) invoke using the participant list in an INVITE request 



Procedure 


Message received from served 
user 


Messages sent to the Conference AS or remote user 


Beginning the 3PTY 


FACILITY^ 
Facility IE 

Begin3PTY-lnv 
Call reference IE 

Call reference of call A-B 


INVITE Request URI: <userCactive@domain.com> 
SDP: a=sendonly 

INVITE Request URI: conference factory URI 

To: CONF AS 

From: userA@domain.com 

Require: recipient-list-invite 

<?xml version="1 .0" encoding="UTF-8"?> 
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" 
xmlns:cp="urn:ietf:params:xml:ns:copyControl"> 
<list> 

<entry uri="userBonHold@domain.com?Call-ID=1 a& 
From=userA@domain.com%3Btag%3Da&To=B%3Btag%3Db" 
cp:copyControl="to"/> 

<entry uri=userCactive@domain.com?Call-ID=2a& 
From=userA@domain.com%3Btag%3Da&To=C%3Btag%3Dc 
cp:copyControl="to"/> 
</list> 
</resource-lists> 
> 



£75/ 



77 



ETSI TS 183 036 V3.3.1 (2010-04) 



Table 5.2.13.2-3: Three-party (3PTY) invoke 



Procedure 


IVIessage received from 
served user 


lUlessages sent to the Conference AS or remote user 


End of three party 

Creation of a private 

communication 

with B 

Creation of a private 

communication 

withC 

Disconnect the 
remote user B 

Disconnect the 
remote user C 


FACILITY^ 
Facility IE 

End3PTY-lnv 
Call reference IE 

Call reference of call A-B 


INVITE Request URI: < userBonHold@domain.com> 
SDP: a=sendonly (see note) 

INVITE Request URI: <userCactive@domain.com> 
<conference-info> 
<conference-state> 

<active>false< active/> 


SDP: a=sendrecv (see note) 

BYE Request URI: conference factory URI 


HOLD^ 

Call reference IE 

Call reference of call A-C 


INVITE Request URI: <userCactive@domain.com> 
SDP : a=sendonly 


RETRIEVE^ 
Call reference IE 

Call reference of call A-B 


INVITE Request URI: < userBonHold@domain.com> 
<conference-info> 


<conference-state> 


<active>false< active/> 


SDP: a=sendrecv 


FACILITY^ 
Facility IE 

End3PTY-lnv 
Call reference IE 

Call reference of call A-C 


INVITE Request URI: < userBonHold@domain.com> 
<conference-info> 
<conference-state> 


<active>false< active/> 


SDP: a=sendonly 

INVITE Request URI: <userCactive@domain.com> 
<conference-info> 
<conference-state> 

<active>false< active/> 
SDP : a=sendrecv 

BYE Request URI: conference factory URI 


DISCONNECT^ 
Call reference IE 

Call reference of call A-B 


BYE Request URI: < userBonHold@domain.com> 

INVITE Request URI: <userCactive@domain.com> 
<conference-info> 
<conference-state> 

<active>false< active/> 


SDP : a=sendrecv 

BYE Request URI: conference factory URI 


DISCONNECT^ 
Call reference IE 

Call reference of call A-C 


BYE Request URI: userCactive@domain.com 

INVITE Request URI: < userBonHold@domain.com> 
SDP: a=sendonly 

BYE Request URI: conference factory URI 


RETRIEVE^ 
Call reference IE 

Call reference of call A-B 


INVITE Request URI: < userBonHold@domain.com> 
<conference-info> 
<conference-state> 

<active>false< active/> 
SDP: a=sendrecv 


NOTE: The a line att 


ribute depends on the Call refer 


3nce of the Facility with the EndSPTY-lnv component. 
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Table 5.2.13.2-4 describes the actions taken when user B or user C disconnects. 

Table 5.2.13.2-4: user B or user C disconnects 



Messages sent to or 

received from 

served user 


Call A-B: Active-held connection 

messages sent to B/AS or received from 

B 


Call A-C: Active-idle connection 

message sent to C/AS or received 

from C 


^DISCONNECT 
Call reference IE 

Call reference of call A-B 


^BYE Request URI <userA@domain.com> 


INVITE^ 

Request URI: 

<userCactive@domain.com> 
<conference-info> 
<conference-state> 

<active>false< active/> 
SDP: a=sendrecv 

BYE^ 

Request URI: conference factory URI 


^DISCONNECT 
Call reference IE 

Call reference of call A-C 


INVITE^ 

Request URI: < userBonHold@domain.com> 
SDP: a=sendonly 

BYE^ 

Request URI: conference factory URI 


^BYE Request URI 
<userA@domain.com> 


RETRIEVE^ 
Call reference IE 

Call reference of call A-B 


INVITE^ 

Request URI: < userBonHold@domain.com> 
<conference-info> 
<conference-state> 


Not applicable 


<active>false< active/> 


SDP: a=sendrecv 



5.2.1 3.3 Notification received at T reference point 

Table 5.2.13.3-1 : Receipt of a 3PTY notification from a private network 



NOTIFY^ 


UPDATE/INVITE ^ 


Notification indicator 
information element 


<conference-info> 


Notification description 


<conference-state> 


100 0010 
Conference established 


<active>true< active/> 


100 0011 
Conference disconnected 


<active>false< active/> 


111 1001 
Remote hold 


SDP a=sendonly 



5.2.1 3.4 Notification received at T reference point 

Table 5.2.13.4-1 : Receipt of a 3PTY notification from a private network 



<- INVITE/UPDATE 


<-NOTIFY 


<conference-info> 


Notification indicator 
information element 


<conference-state> 


Notification description 


<active>true< active/> 


100 0010 
Conference established 


<active>false< active/> 


100 0011 
Conference disconnected 


SDP a=sendonly 


111 1001 
Remote field 
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5.2.1 4 Completion of Call to Busy Subscriber (CCBS) 
5.2.1 4.1 Actions at the outgoing AGCF/VGW 

CCBS Invocation 

In case the terminating user is busy, a 183 Session Progress is received. The activation of the CCBS service is possible 
after the announcement is applied by the AS. The user provides the activation by performing in-band dialogue or by 
sending the proper service code via keypad protocol. The service code received in the Keypad Facility Information 
Element is used to construct the user part of the Request line of the INVITE request sent to the CCBS Application 
Server. These requirements are described in annex A of the present document. The result is available in-band 
(announcement). 

After the activation procedure was successful, a 486 is received and the connection is terminated according the 
procedures as described in clause 5.1.1.4. 

Starting CCBS recall 

Two procedures are applicable to perform the CCBS recall: 

1) When the AGCF/VGW receives a REFER request and the Request-URI is set to the URI of the served user 
from the original communication, including a "m" SIP URI parameter with a value set to "BS" then a SETUP 
is sent to the DSSl user equipment. If a DSSl CONNECT message is received (the served user accepts the 
recall) then an INVITE request is sent and the Request URI is set equal to the URI received in the Refer-To 
header of the previous REFER. The DSSl dialogue and the INVITE dialogue have to be associated. 

Table 5.2.14.1-1 : Recall procedure by reception of REFER request 



^ SETUP 


^ REFER 




Request URI <served user>; m=BS 


Refer-To: <user B> 



2) When the AGCFA'^GW receives an INVITE request including a "m" SIP URI parameter with a value set to 
"BS", A SETUP is sent to the DSSl user equipment. When a CONNECT is received, a 200 OK INVITE 
response is sent. This is the trigger for the AS to send an INVITE request to the monitored user. 

Table 5.2.14.1-2: Recall procedure by reception of INVITE request 



^ SETUP 


^ INVITE 




Request URI <served user>; m=BS 



Revocation of CCBS request 

A CCBS request can be cancelled using the keypad facility protocol. These requirements are described in annex A of 
the present document. The DSSl connection and the SIP dialogue are terminated after the revocation was successful 
according normal DSSl and SIP procedures. 

NOTE: All outstanding CCBS requests cancelled. 

5.2.1 4.2 Actions at the incoming AGCF/VGW 

No special requirements. Procedures as described in clause 5.1.2.1 apply. 

5.2.1 5 Completion of Calls on No Reply (CCNR) 
5.2.1 5.1 Actions at the outgoing AGCF/VGW 

CCNR Invocation 
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In case the terminating user is not busy, a 180 Ringing is received. The activation of the CCNR service is possible after 
the announcement is applied by the AS. The user provides the activation by performing in-band dialogue or by sending 
the proper service code via keypad protocol. The service code received in the Keypad Facility Information Element is 
used to construct the user part of the Request line of the INVITE request sent to the CCNR Application Server. These 
requirements are described in annex A of the present document. The result is available in-band (announcement). 

Starting CCNR recall 

Two procedures are applicable to perform the CCNR recall: 

1) When the AGCF/VGW receives a REFER request and the Request-URI is set to the URI of the served user 
from the original communication, including a "m" SIP URI parameter with a value set to "NR" then a SETUP 
is sent to the DSSl user equipment. If a DSSl CONNECT message is received (the served user accepts the 
recall) then an INVITE request is sent and the Request URI is set equal to the URI received in the Refer-To 
header of the previous REFER. The DSSl dialogue and the INVITE dialogue have to be associated. 

Table 5.2.15.1-1 : Recall procedure by reception of REFER request 



<r- SETUP 


<r- REFER 




Request URI <served user>; m=NR 


Refer-To: <user B> 



2) When the AGCFA'^GW receives an INVITE request including a "m" SIP URI parameter with a value set to 
"NR", A SETUP is sent to the DSSl user equipment. When a CONNECT is received, a 200 OK INVITE 
response is sent. This is the trigger for the AS to send an INVITE request to the monitored user. 

Table 5.2.15.1-2: Recall procedure by reception of INVITE request 



<- SETUP 


<- INVITE 




Request URI <served user>; m=NR 



Revocation of CCNR request 

A CCNR request can be cancelled by performing in-band dialogue or using the keypad facility protocol. These 
requirements are described in annex A of the present document. 

The DSSl connection and the SIP dialogue are terminated after the revocation was successful according normal DSSl 
and SIP procedures. 

NOTE: All outstanding CCNR requests are cancelled. 

5.2.1 5.2 Actions at the incoming AGCF/VGW 

No special requirements. Procedures as described in clause 5.1.2.1 apply. 

NOTE: Information received from the served user in the recall phase will not transported to the terminating user. 

5.2.16 Advice Of Charge AOC 

As described in [31], three AOC supplementary services exist: 

a) Charging information at communication set-up time (AOC-S) 

The AOC-S service enables a user to receive information about the charging rates at communication 
set-uptime and also to receive further information during the communication if there is a change of charging 
rates. 

b) Charging information during the communication (AOC-D) 

The AOC-D service enables a user to receive information on the recorded charges for a communication during 
the active phase of the communication. 
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c) Charging information at the end of the communication (AOC-E) 

The AOC-E service enables a user to receive information on the recorded charges for a communication when 
the communication is terminated. 

5.2.1 6.1 Actions at the outgoing AGCF/VGW 

Transfer of AOC-S charging information 

The AOC-S charging information is transported during the call establishment, during the call (change in rates). 

During the call establishment, the AOC-S information shall be carried in SIP Ixx provisional response or a 200 OK 
response to an INVITE message, in a MIME body type "application/vnd.etsi.aocH-xml" defined in 
TS 183 047 [31]. 

It's mapped to a Facility information element in a DSSl ALERTING, CALL PROCEEDING, PROGRESS, or 
CONNECT message. 

During the call, the AOC-S information shall be carried in a SIP INFO message in a MIME body type 
"appHcation/vnd.etsi.aocH-xml" defined in TS 183 047 [31]. 

It's mapped to a Facility information element in a DSSl FACILITY message. 

Table 5.2.16.1-1 : Transport of AOC-S 



SIP messages -^ 
1xx, 200 OK (INVITE), INFO 


DSSl messages -^ 
ALERTING, CALL PROCEEDING, 
PROGRESS, CONNECT, FACILITY 


MIME body type "application/vnd.etsi.aoc+xml" 

aoc 
aoc-s 


Facility Information Element 

ChargingRequest 

charginglnformationAtCallSetup 



NOTE: The feature "the served user is the terminating user" doesn't exist for the ISDN, because of this mapping 
from the INVITE request to a SETUP message is not possible. 

Transfer of AOC-D charging information 

The AOC-D charging information is transported during the call. 

The AOC-D information shall be carried in a SIP INFO message in a MIME body type "application/vnd.etsi.aocH-xml" 
defined in TS 183 047 [31]. 

It's mapped to a Facility information element in a DSSl FACILITY message. 

Table 5.2.16.1-2: Transport of AOC-D 



SIP messages -^ 
INFO 


DSSl messages^ 
FACILITY 


MIME body type "application/vnd.etsi.aoc+xml" 

aoc 
aoc-d 


Facility Information Element 

ChargingRequest 

chargingDuringACall 



Transfer of AOC-E charging information 

The AOC-E charging information is transported during the call clearing. 

The AOC-E information shall be carried in a SIP 200 OK response to a BYE message (if the party that has subscribed 
to the AOC-E service clears the call) or in a SIP BYE message (if the party that has subscribed to the AOC-E service 
receives the release of the call), in a MIME body type "application/vnd.etsi.aoc+xml" defined in TS 183 047 [31]. 

It's mapped to a FaciHty information element in a DSSl DISCONNECT, RELEASE, RELEASE COMPLETE message. 
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Table 5.2.16.1-3: Transport of AOC-E 



SIP messages -^ 
BYE, 200 OK (BYE) 


DSS1 messages -^ 

DISCONNECT, RELEASE, RELEASE 

COMPLETE 


MIME body type "application/vnd.etsi.aoc+xml" 

aoc 
aoc-e 


Facility Information Element 

CtiargingRequest 

ctiargingAtTlieEndOfACall 



When processing originating sessions with multiple call legs to be charged, e.g. in 3-party calls or when using the 
conference service, then the Application server shall send charging information separately for each call leg to the 
AGCF/VGW. 

As an alternative dependent on the setting of a network operator option the Application server may send charging 
information related to the affected call legs in one single AOC xml body in a combined representation. 

As a consequence the AGCF/VGW in accordance with the Application server shall process charging information 
received from the Application Server in one of the following manners: 

• The AGCFA^GW shall be able to process bodies with AOC information which are separately received for the 
different call legs. 

• As a network operator option the charging information received may be assumed as a combined representation 
applying to all call legs. If only one dialog exists between the AGCF/VGW and the AS, the AGCF/VGW is 
not informed when one of the far parties is released. In order to ensure that charging is accurate, the AS will 
have to send an INFO request with an XML body each time a far party is added or released, regardless of 
whether AOC-S, AOC-D, or AOC-E has been chosen as the desired reporting technique. 

5.2.17 Message Waiting Indication (MWI) 

Upon receipt of a NOTIFY request containing the following headers 

• Event: message-summary 

• Subscription-State: active 

• Content-Type: application/simple-message-summary 

• Messages-Waiting: yes 

A DSSl FACILITY message is sent to the DSSl user equipment. The mapping of the Facility I.E is described in 
table 5.2.17-1. 
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Table 5.2.17-1 : Mapping of NOTIFY into DSS1 FACILITY 



NOTIFY ^ 


FACILITY ^ 


Event: message-summary 

Subscription-State: active 

Content-Type: application/simple-message-summary 

IVIessages-Waiting: yes 


Facility Information Element: MWIIndicate invoke 


IVIessage-Account: 


controllingUserProvidedNr 


[msg-summary-line] 

Voice-Message: new/old 
Fax-IVIessage: new/old 
Video-Message: new/old 
(NOTE) 


basicService 
speech 

telefaxGroup2-3 
videotelephony 


[msg-summary-line] 

Voice-Message: new/old 
Fax-Message: new/old 
Video-Message: new/old 
(see note) 


basicService 
speech 

telefaxGroup2-3 
videotelephony 


NOTE: All other Internet Message Content Types are not able to map into the basic service. However an ISDN 
terminal does not have the capability to receive these types. 



Upon receipt of a NOTIFY request a 200 OK (NOTIFY) is send according normal SIP procedures. 

5.3 DSS1 layer 2 failure 

5.3.1 DSS 1 data link reset and data link failure procedures in the 
outgoing AGCF/VGW 

The data link reset and data link failure procedures are respectively described in 5.2.8.8 and 5.2.8.9/Q.931 [54]. 
Table 5.3.1-1 : DSS 1 data link reset and data link failure procedures 



^-DISCONNECT 


Trigger event 


BYE/CANCEL^ 


Cause Information element 

(see note 2) 


Reason header 


Cause value No. 41 
{temporary failure) 


Data link reset in overlap sending state 


Cause value No. 41 
{temporary faiiure) 


(see note 1 ) 


Data link failure in another state than active state 


Cause value No. 27 
{destination out of order) 


(see note 1 ) 


Failure of the data link reestablishment procedure 
after a data link failure in active state 


Cause value No. 27 
{destination out of order) 


NOTE 1 : The call is cleared internally. No DISCONNECT message is sent on the access. 
NOTE 2: The location is coded '1010' network beyond interworking point. 



5.3.2 DSS 1 data link reset and data link failure procedures in the 
incoming AGCF/VGW 

The data link reset and data link failure procedures are respectively described in 5.8.8 and 5.8.9/Q.931 [54]. 
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Table 5.3.2-1 : DSS 1 Data link reset and Data link failure procedures 



^ BYE/4XX/5XX 


Trigger event 


DISCONNECT^ 


Reason header 




Cause information element 

(see note 2) 


cause No. 41 
(temporary failure) 


Data link reset 

in overlap receiving state 


Cause value No. 41 
(temporary failure) 


cause No. 27 
(destination out of order) 


Data link failure 

in another state than active state 


(see note 1) 


cause No. 27 
(destination out of order) 


Failure of the data link reestablishment procedure 
after a data link failure in active state 


(see note 1) 


NOTE 1 : The call is cleared internally. No DISCONNECT message is sent on the access. 
NOTE 2: The location is coded '1010' network beyond intem/orking point. 



5.3.3 Release by the outgoing AGCF/VGW 

Table 5.3.3-1 : Release from the originating AGCF/VGW 



^-DISCONNECT 


Trigger event 


BYE/CANCEL^ 


Cause information element 

(see note 3) 


Reason header 


Cause value No. 28 

Invalid number format (address 

incomplete) 


Determination that the called number information 
received is incomplete, after an lAM message has 
already been sent 


Cause value No. 28 

Invalid number format (address 

incomplete) 


Same cause value as in the 
REL message 
(see note 1 ) 


Other cases of failure on the SIP side 


Cause value coded 
according to [4] 


Cause value coded 
according to [6] 


Other cases of failure on the DSS 1 side 


Same cause value as in the 
DISCONNECT message 
(see note 2) 


NOTE 1 : If the cause value sent in the BYE/CANCEL message is unknown in DSS 1 , the unspecified cause value of 

the class is sent. 
NOTE 2: If the cause value sent in the DISCONNECT message is unknown in SIP, the unspecified cause value of the 

class is sent. 
NOTE 3: The location is coded '1010' network beyond intenvorking point. 
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5.3.4 Release by the AGCF/VGW 



Table 5.3.4-1 : Release from the terminating AGCF/VGW 



^-Message sent to the SIP 


Trigger event 


Message sent to the DSS 1 -^ (see note 3) 


Point-to-point data link 


Broadcast data link 


480 

Cause value No. 18 

No user responding 


No response to the 
SETUP message 
(T303 expiry) 


DISCONNECT 
Cause value No. 102 
Recovery on timer expiry 


No action 


480 

Cause value No. 18 

No user responding 


No ALERTING, CONNECT 
or DISCONNECT after 
CALL PROCEEDING 
(T3 10 expiry) 


DISCONNECT 
Cause value No. 102 
Recovery on timer expiry 


RELEASE 

Cause value No. 102 

Recovery on timer expiry 


480 

Cause value No. 19 

No answer from user (user 

alerted) 


No CONNECT or 
DISCONNECT after 
ALERTING 
(T301 expiry) 


DISCONNECT 
Cause value No. 102 
Recovery on timer expiry 


RELEASE 

Cause value No. 102 

Recovery on timer expiry 


480 

Cause value No. 31 

Normai, unspecified 


Unsuccessful termination of 
the B-channel selection 
procedure 


RELEASE 

Cause 6 

Channei unacceptabie 


500 

Cause value coded 

according to [4] 


Other cases of failure on the 
SIP side 


DISCONNECT 

Same cause value as in the 

REL message 

(see note 1) 


500 

Same cause value as in the 
DISCONNECT message 
(see note 2) 


other cases of failure on the 
DSS 1 side 


DISCONNECT 
Cause value coded 
according to [6] 


NOTE 1 : If the cause value sent in the 480/500 message is unknown in DSS 1 , the unspecified cause value of the 

class is sent. 
NOTE 2: If the cause value sent in the DISCONNECT message is unknown in SIP, the unspecified cause value of the 

class is sent. 
NOTE 3: The location is coded '1010' networi< beyond interwori<ing point. 



5.4 Service operation 

5.4.1 Call related service operation 

5.4.1 .1 Malicious Call Identification (MCID) 

The invocation of Malicious Call Identification is described in clause 5.2.6. 

When a 200 OK INVITE is received as the final response to the relNVITE containing the MCID request, a 
mCIDRequest return result component is sent to the served user equipment. 

If an unsuccessful final response is received, a mCIDRequest return error component error code "not Available" is 
sent the user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

The coding of the FACILITY message and the Facility I.E is described in [20]. 

5.4.1 .2 Explicit Communication Transfer (ECT) 

The mapping of Explicit Communication Transfer related Facility components is described in clause 5.2.7. 

When a 202 Accepted is received, and the NOTIFY message/sipfrag part for both communications indicates the 
successful communication between Transfer target and Transferee, an eCTExecute return result component is sent to 
the served user equipment in the DISCONNECT messages. 
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If an unsuccessful final response was received upon the REFER was sent, an eCTExecute return error component 
value "not Available" is sent to the served user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

The coding of the FACILITY message and the Facility I.E is described in [35]. 

5.4.1 .3 Closed User Group (CUG) 

The mapping of the CUG request and the handling of unsuccessful final responses is described in clause 5.2.9. 

5.4.1 .4 Three Party Service (3PTY) 

The mapping of Three Party Service related Facility components is described in clause 5.2.13. 

When for the INVITE sent to the conference focus to get a "conference URI" the 200 OK is received and the 202 
Accepted for both REFER sent to the remote participants is received, a Begin3PTY return result component is sent to 
the served user equipment. 

If an unsuccessful final response was received upon the INVITE to get the "conference URI" was sent, a Begin3PTY 
return error component value "notAvailable" is sent to the served user equipment. 

If an unsuccessful final response was received upon the REFER to establish the conference was sent, a Begin3PTY 
return error component value "notAvailable" is sent to the served user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

The coding of the FACILITY message and the Facility I.E is described in [24]. 

5.4.1 .5 Completion of Call to Busy Subscriber (CCBS) 

FFS 

5.4.1 .6 Completion of Calls on No Reply (CCNR) 

FFS 

5.4.2 Call independent service configuration 

Call independent service can be achieved using either the Gm reference point or the Ut reference point. In case of the 
Gm reference point the MESSAGE method is used to convey the service related information to the relevant target. In 
general the information to configure a service is embedded in a XML instance document contained in the MESSAGE 
request. In the case of the Ut reference point, HTTP PUT, HTTP GET or HTTP DELETE requests are used in 
accordance with RFC 4825 [48] and the supplementary services application usage specified in TS 183 023 [49]. 

The following clauses specify the mapping between the ROSE components embedded in DSS.l FACILITY messages 
and the XML document to be created. 

5.4.2.1 Communication Diversion Services (CDIV) 

5.4.2.1.1 Communication Diversion activation 

On receipt of a DSSl FACILITY message containing the ActivationDiversion invoke component, a SIP MESSAGE 
request or a HTTP request is sent that contains a XML "communication-diversion" instance to the Application Server. 
The attribute of the communication-diversion element is "true". The mapping of the Facility I.E is described below. 
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Table 5.4.2.1.1-1: Mapping of conditions 



FACILITY -^ 


MESSAGE or HTTP PUT Request ^ 


Activation Diversion invoke 


<communication-diversion active="true" 


Procedure 


cfu 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 


(see note 1 ) 


cfb 


<busy/> 


cfnr 


<no-answer/> 


basicService 


Speech 
audio3k 
64kbit 


<cp:ruleset> 

<cp:rule id="<rule id "> 

<cp:conditions> 

<media> 


(see note 2) 


servedUserNr 


PartyNumber 


P-Preferred-ldentity or P-Asserted- 
Identity header (see notes 3 and 4) 




NOTE 1 : In case unconditional call forwarding no corresponding <cp:condition> element is included. 

NOTE 2: The list of basic services is contained in EN 300 196-1 [25]. The string value shall be set to ASN1 
enumerated numeric value of BasicService type in EN 300 196-1 [25] clause D.6. Activation of call 
forwarding for all basic services is achieved by omitting the <media> condition. 

NOTE 3: The servedUSerNr is mapped to either the P-Preferred-ldentity header by a VGW or the 
P-Asserted-ldentity header by an AGCF. 

NOTE 4: Mapping of the ISDN value "allNumbers" requires further study. 



Table 5.4.2.1.1-2: Mapping of actions 



FACILITY ^ 


MESSAGE or HTTP PUT Request -^ 


ActivationDiversion invoke 


<communication-diversion active="true" 


forwardedToAddress 


Public number 


<cp:ruleset> 

<cp:rule id="<rule id"> 
<cp:actions> 

<ss:forward-to> 
<ss:target> 


userC@domain 


noReplyTimer 


int 


<cp:ruleset> 

<cp:rule id="<rule id"> 
<cp:actions> 

<ss:forward-to> 

<ss:NoReplyTimer> 


20 



On receipt of a 200 OK MESSAGE or HTTP response, a DSSl FACILITY message including the ActivationDiversion 
return result component is sent to the DSSl user equipment. 

If an unsuccessful final response is received upon sending a MESSAGE or HTTP Request including a XML 
communication-diversion instance, a DSSl FACILITY message including the ActivationDiversion return error 
component value "not Available" is sent to the DSSl user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

Additionaly to activate the CDIV service, as a network option it is possible to use service code commands via in-band 
dialogue or using the service code via keypad protocol. These requirements to using the keypad protocol are described 
in annex A of the present document. The result is available in-band (announcement). 



5.4.2.1.2 



Communication Diversion deactivation 



On receipt of a DSSl FACILITY message containing the DeactivationDiversion invoke component, a SIP MESSAGE 
request or a HTTP Request is sent that contains a XML "communication-diversion" instance to the Application 
Server. The attribute of the communication-diversion element is "false". The mapping of the Facility I.E is described 
below. 
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Table 5.4.2.1.2-1 : Mapping of conditions 



FACILITY -^ 


MESSAGE or HTTP PUT Request -^ 


DeactivationDiversion invoke 


<communication-diversion active="false" 


procedure 


cfu 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 


(N0TE1) 


cfb 


<busy/> 


cfnr 


<no-answer/> 


basicService 


Speech 
audio3k 
64kbit 


<cp:ruleset> 

<cp:rule id="<rule id "> 

<cp:conditions> 

<media> 


(see note 2) 


servedUserNr 


PartyNumber 


P-Preferred-ldentity or P-Asserted-ldentity 
header (see notes 3 and 4) 




NOTE 1 : In case unconditional call forwarding no corresponding <cp:condition> element is included. 

NOTE 2: The list of basic services is contained in EN 300 1 96-1 [25]. The string value shall be set to ASN1 enumerated 

numeric value of BasicService type in EN 300 196-1 [25] clause D.6. Deactivation of call forwarding for all 

basic services is achieved by omitting the <media> condition. 
NOTE 3: The servedUSerNr is mapped to either the P-Preferred-ldentity header by a VGW or the P-Asserted-ldentity 

header by an AGCF. 
NOTE 4: IVIapping of the ISDN value "allNumbers" requires further study. 



On receipt of a 200 OK MESSAGE or HTTP successful response, a DSSl FACILITY message including the 
DeactivationDiversion return result component is sent to the DSSl user equipment. 

If an unsuccessful final response is received upon sending a MESSAGE or HTTP Request including a XML 
communication-diversion instance, a DSSl FACILITY message including the DeactivationDiversion return error 
component value "not Available" is sent to the DSSl user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

Additionaly to deactivate the CDIV service, as a network option it is possible to use service code commands via in-band 
dialogue or using the service code via keypad protocol. These requirements to using the keypad protocol are described 
in annex A of the present document. The result is available in-band (announcement). 



5.4.2.1.3 



Communication Diversion interrogation 



On receipt of a DSSl FACILITY message containing the InterrogationDiversion invoke component, a SIP 
MESSAGE or HTTP request is sent that contains a XML "communication-diversion" instance to the Application 
Server. The mapping of the Facility I.E is described below. 
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Table 5.4.2.1.3-1 : Mapping of InterrogationDiversion invoke 



FACILITY -^ 


MESSAGE request or HTTP GET request -^ 


InterrogationDiversion invoke 


<communJcation-diversion> 


procedure 


cfu 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 


(see note 1 ) 


cfb 


<busy/> 


cfnr 


<no-answer/> 


basicService 


Speech 
audio3k 
64kbit 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 
<ss:media> 


(see note 2) 


servedUserNr 


PartyNumber 


P-Preferred-ldentity or P-Asserted-ldentity 
header (see notes 3 and 4) 




NOTE 1 : In case unconditional call forwarding no corresponding <cp:condition> element is included. 

NOTE 2: The list of basic services is contained in EN 300 1 96-1 [25]. The string value shall be set to ASN1 

enumerated numeric value of BasicService type in EN 300 196-1 [25] clause D.6 Interrogation of call 
forwarding for all basic services is achieved by omitting the <media> condition. 

NOTE 3: The servedUSerNr is mapped to either the P-Preferred-ldentity header by a VGW or the P-Asserted- 
Identity header by an AGCF. 

NOTE 4: IVIapping of the ISDN value "allNumbers" requires further study. 



On receipt of a MESSAGE request or HTTP successful response that contains a "communication-diversion" XML 
instance, a DSSl FACILITY message is sent to the served user equipment. The mapping of the XML instance into the 
Facility I.E InterrogationDiversion invoke return result is described below. 

Table 5.4.2.1.3-2: IVIapping of InterrogationDiversion result 



^ FACILITY 


<- MESSAGE request or HTTP GET response 


InterrogationDiversion return result 


<communication-diversion active="true" 


procedure 


cfu 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 


(see note 1) 


cfb 


<busy/> 


cfnr 


<no-answer/> 


basicService 


Speech 
audio3k 
64kbit 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 
<ss:media> 


(see note 2) 


servedUserNr 


PartyNumber 


P-Preferred-ldentity or P-Asserted-ldentity 
header (see notes 4 and 5) 




forwardedToAddress 


Public number 


<cp:ruleset> 

<cp:rule id="<rule id"> 
<cp:actions> 

<ss:forward-to> 
<ss:target> 


userC@domain 
(see note 3) 


NOTE 1 : If the <busy/> and <no-answer/> conditions are absent from the XIVIL document, the "procedure" element is 

set to "cfu". 
NOTE 2: The list of basic services is contained In EN 300 1 96-1 [25]. The string value shall be set to ASN1 

enumerated numeric value of BasicService type in EN 300 196-1 [25] clause D.6. If the <media> element is 

absent, the basicService element is set to allServices. 
NOTE 3: If the country code is equal to the country code where the AGCF/VGW is located, the country code is 

removed from the number string and the Type of Number is set to "national number" else the number string 

is sent unchanged and the Type of number is set to "international number". 
NOTE 4: The servedUSerNr is mapped to either the P-Preferred-ldentity header by a VGW or the P-Asserted-ldentity 

header by an AGCF. 
NOTE 5: IVIapping of the ISDN value "allNumbers" requires further study. 



If an unsuccessful final response is received upon sending a MESSAGE or HTTP Request including a XML 
"communication-diversion" instance, a DSSl FACILITY message including the InterrogationDiversion return 
error component value "not Available" is sent to the DSSl user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 
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Additionaly to interrogate the status of the CDIV service, as a network option it is possible to use service code 
commands via in-band dialogue or using the service code via keypad protocol. These requirements to using the keypad 
protocol are described in annex A of the present document. The result is available in-band (announcement). 

5.4.2.1 .4 Activation Status Notification Diversion 

Mapping of this procedure requires further study. 



5.4.2.2 



Message Waiting Indication (IVIWI) 



5.4.2.2.1 



Activation of Message Waiting Indication (MWI) 



On receipt of a DSSl FACILITY message containing the MWIActivate invoke component, a SIP SUBSCRIBE 
request is sent to the Application Server that contains an Event header and the value is set to "message-summary" 
additionally the Accept header contains the value "application/simple-message-summary". The Expires header contains 
the subscription duration. The mapping of the Facility I.E is described below. 

Table 5.4.2.2.1-1 : Mapping of MWIActivate invoke 



FACILITY ^ 


SUBSCRIBE ^ 


Facility Information Element: MWIActivate invoke 


Event: message-summary 

Expires: xxxxx (user option) 

Accept: application/simple-message-summary 


receivingUserNr 


From: 


basicService 




controllingUserProvidedNr 


Request URI 


controllingUserNr (see note) 


Request URI 


NOTE: If only the "controllingUserNr" parameter is present, this parameter shall be mapped into the Request 
URI. In the other case the "controllingUserProvidedNr" parameter has precedence. 



On receipt of a 200 OK (SUBSCRIBE) or 202 OK (SUBSCRIBE) and the Expires header is not equal to zero, a DSSl 
FACILITY message including the MWIActivate return result component is sent to the DSSl user equipment. 
If an unsuccessful final response is received upon sending a SUBSCRBE, a DSSl FACILITY message including the 
MWIActivate return error component value "resourceUnavailable" is sent to the DSSl user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

Additionaly as to activate the MWI service, as a network option it is possible to use service code commands via in-band 
dialogue or using the service code via keypad protocol. These requirements to using the keypad protocol are described 
in annex A of the present document. The result is available in-band (announcement). 



5.4.2.2.2 



Deactivation of Message Waiting Indication (MWI) 



On receipt of a DSSl FACILITY message containing the MWIDeactivate invoke component, a SIP SUBSCRIBE 
request is sent to the Application Server the Event header I set to "message-summary" and the Expires header is set to 
zero. The mapping of the Facility I.E is described below. 

Table 5.4.2.2.2-1 : Mapping of MWIDeactivate invoke 



FACILITY -^ 


SUBSCRIBE^ 


Facility Information Element: MWIDeactivate invoke 


Event: message-summary 
Expires: 


receivingUserNr 


From: 


basicService 




controllingUserProvidedNr 


Request URI 


controllingUserNr (see note) 


Request URI 


NOTE: If only the "controllingUserNr" parameter is present, this parameter shall be mapped into the Request 
URI. In the other case the "controllingUserProvidedNr" parameter has precedence. 
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On receipt of a 200 OK (SUBSCRIBE), a DSSl FACILITY message including the MWIDeactivate return result 
component is sent to the DSSl user equipment. 

If an unsuccessful final response is received upon sending a SUBSCRIBE, a DSSIFACILITY message including the 
MWIDeactivate return error component value "resourceUnavailable" is sent to the DSSl user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

Additionaly as to deactivate the MWI service, as a network option it is possible to use service code commands via in- 
band dialogue or using the service code via keypad protocol. These requirements to using the keypad protocol are 
described in annex A of the present document. The result is available in-band (announcement). 
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Annex A (normative): 
Keypad Procedures 

A.1 Generic procedure at the AGCF/VGW side 

On receipt of a service code included within a Keypad facility information element included within a SETUP and/or 
INFO Message(s), the AGCF/VGW sends an INVITE request with the following information: 

• A Request-URI structured as follows: 

A user part containing the service code command, excluding the START and FINISH fields. The same 
Syntax is used as for PSTN. This is shown in clause Cl.2.1.1 in TS 183 043 [42]. 

A domain name which together with the user part provides sufficient information to the S-CSCF to 
forward the INVITE request to the appropriate AS, based on Initial Filter Criteria stored in the user 
profile, e.g. 

"PX SC (SR SI) SX"@ pes-scc.operator.com 

NOTE 1 : If the service code command includes a square "#" symbol, the userinfo portion of the Request-URI shall 
be in the form of a telephone-subscriber. The series of digits that form the service code command shall be 
encoded as a local-number. The phone-context attribute shall be set to a domain name of the PES 
operator, e.g. phonecontext=pes-scc.homedomain.com that is specific enough to enable the application 
server to interpret the commandecode. Setting the phone-context attribute is required for conformance 
purposes with RFC 3966 [47]. PES network entities (e.g. CSCF) ignore this attribute. 

NOTE 2: In cases where Overlap Signalling is used the regarding rules for Overlap are used. The collection of the 
Service Code Information is done within the related Application Server. 

• To Header: Same info as in R-URI. 

• A P-Asserted-Identifier header containing the public user identity of the subscriber issuing the service code 
command. 

• An SDP offer for a voice call. 

NOTE 3: The SDP offer may be used by the Application Server in case an announcement has to be delivered. 



A.2 Generic procedure at the AS side 

The procedures used at the AS Side are the same as for PSTN as described within TS 183 043 [42], clause C. 1.2. 1.3. 
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Annex B (normative): 

SDP mapping for ISDN 7 kHz service and Inter-working 



B.1 Originating Side 



DSS1 VGW / AGCF 


Toward Far End 


=> DSS1 


SIP INVITE SDP- OFFER => 


BC1 =3,1 kHz audio 


CLEARMODE, PCMA or PCMU 


DSS1-VGW 

orDSS1-AGCF 

or MGCP 

or SIP Phone 7 kHz 

or SIP Phone 3,1 kHz 


BC2 = Unrestricted Digital Info with 
tones/announce 



DSS1 VGW / AGCF 


From Far End 


<= DSS1 


SIP SDP- ANSWER <= 


BC = Unrestricted Digital Info with 
tones/announce (see note 1 ) 


CLEARMODE, PCMA or PCMU 


DSS1-VGW 

DSS1- AGCF or MGCP 


BC = 3,1 kHz (see note 2) 


PCMA/PCMU 


SIP Phone 3,1 kHz or 
SIP Phone 7 kHz (see 
note) 


NOTE: It is assumed that the SIP 7 KHz phone only supports the G.722 codec natively and thus does not understand 
the CLEARMODE codec. 



B.2 Terminating side 



a) Case 1 



DSS1 VGW / AGCF (see note 1 ) 


Far end 


<= DSS1 


SIP INVITE SDP- OFFER<= 


DSS1-VGW 

DSS1-AGCF 

or MGCP 


BC1=3,1 kHz audio 

BC2 = Unrestricted Digital Info with 

tones/announce 


CLEARMODE, PCMA or PCMU 


=>DSS1 


SIP INVITE SDP- ANSWER=> 


BC2 = Unrestricted Digital Info with 
tones/announce 


CLEARMODE, PCMA or PCMU 



b) Case 2 



DSS1 VGW / AGCF (see note 2) 


Far end 


<=DSS1 


SIP INVITE SDP- OFFER <= 


SIP Phone 7 kHz 


BC = 3,1 kHz 


G.722, PCMA, PCMU 


=>DSS1 


SIP INVITE SDP- ANSWER=> 


BC = 3,1 kHz 


PCMA/PCMU 





c) Case 3 



DSS1 VGW / AGCF (see note 2) 


Far end 


<=DSS1 


SIP INVITE SDP- OFFER<= 


SIP Phone 3,1 kHz 


BC = 3,1 kHz 


PCMA, PCMU 


=>DSS1 


SIP INVITE SDP- ANSWER=> 


BC = 3,1 kHz 


PCMA/PCMU 



NOTE 1: VGW/AGCF Media handling = H.221 structure is carried transparent from end to end. 
NOTE 2: VGW/ AGCF media handling = PCMA/PCMU is carried transparent. 
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Annex C (normative): 
Timers 



This annex specifies the use of the different ISUP, SIP and ISDN timers. 



0-MGCF 



IAM(797) 



INVITE(797) 



y T|sup1 0(4-6 sec) 
SAM(1) 



Tisup 1 (4-6 sec) 
SAM(1) 



SAM(1312) 



Tisup1 0(4-6 sec) 



Ti/w2 (4-14 sec) 



ACM(BCi: no indication) 



l/S-CSCF 



484 (iVlin-Length=5) 



ACK 



INViTE(797 11) 



INViTE(797 11 13 12) 



484 



ACK 



183 Session Progress 



X-CSCF 



INViTE(797 11) 



INViTE(797 11 13121 



484 



ACK 



J 83 Session Progress 



AGCFA/GW 



INVITE(797 11) 



INVITE(797 11 1312) 



484 



ACK 



183 Session Progress 



SETUP(797 11) 



TisDN 302 



SETUP ACK 



y T|sdn304 
INFO(1312) 



CALL PROCEEDING 



7 



TisDN 304 



Figure C.I 
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3 



y 



AGCFA/GW 



SETUP 



SETUP ACK I^^^EKCSgll 



TisDN 302 
INFO 



y Tisdn302 
INFO 



INFO 



TisDN 302 



CALL PROCEEDING 



X-CSCF 



WMVITE(CSql) 



INVITE(CSq2) 



484((CSq1) 



ACK 



INVITE(CSq3) 



484(CSq2) 



ACK 



INVITE(CSq4) 



484(CSq3) 



ACK 



183 Session Progress(CSq4) 



l/S-CSCF 



INVITE(CSq2) , 

484(CSqlf 



ACK 



INVITE(CSq3) , 

484(CSq2f 



ACK 



INVITE(CSq4) 



484(CSq3) 



ACK 



J 83 Session Progress 



0-MGCF 



INVITE 



INVITE 



183 Session Progress 



lAM 



V Tisupl 1(15-20 880) 
SAM 



^Tisupll I 



(15-20 880) 
, J ACM (BCi: no indication) 



Figure C.2 



AGCFA/GW 



SETUP 



^ 




SETUP ACK 


"^ 




INFO 








INFO 








INFO 








INFO 








INFO 







CALL PROCEEDING 



X-CSCF 



Linfo 



INVITE Cseq 1 



1 83 Session Progress Cseq 1 



Figure C.3: Overlap withi Tinfo Timer 
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Table C.I : SIP - Timer in the network side 



Timer 
number 


Default time-out 
value 


State of call 


Cause for start 


Normal stop 


At the first expiry 


At the subsequent 
expiry 


Tinfo 


0,5 s to 2 s 


Overlap sending 


SETUP Received 


Timer expired 


INVITE with the 
collected digits 
received in the 
SETUP and INFOs 




TisdnS 


12 s to 17 s (default 
of 12 s) 


Overlap sending 


On receipt of 404 
Not Found or 484 
Address 

Incomplete on the 
latest INVITE 
transactions for the 
corresponding call. 


Subsequent INFO is 
received, on 
reception of 180 
Ringing, or 183 
Session Progress or 
200 OK (INVITE). 


Release call 




^TIRI 


0,1 sto2s 
(default 0,1 s) 


Session answering 


On receipt of 200 
OK INVITE 
including the 
option tag "from- 
change", no 
privacy header or 
privacy value 
none, and Userinfo 
of P-Asserted- 
Identity in the 
format of a tel URI. 


At the receipt of an 
UPDATE 


map the received 
200 OK INVITE to 
a CONNECT 
message 
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Table C.2: ISDN Timers in the AGCF/VGW side- overview 



Timer 
number 


Default time-out 
value 


State of call 


Cause for start 


Normal stop 


At the first expiry 


At the second 
expiry 


Cross-reference 


T301 


IVIinimum 3 min 


Call received 


ALERT received 


CONNECT received 


Clear call 


Timer is not 
restarted 


(see note 2) 


T302 


10sto15s 
(see note 3) 


Overlap sending 


SETUP ACK sent 
Receipt of INFO, 
restarts T302 


With sending 
complete indication, 
or network alert, or 
connect request 
received 


Clear if call 
information 
determined to be 
definitely 
incomplete; else 
send CALL PROC 


Timer is not 
restarted 


Mandatory 


T303 


4s 

(see note 1 ) 


Call present 


SETUP sent 


ALERT, CONNECT 
CALL PROC or 
SETUP ACK 
received, REL 
COMPLETE 
received if SETUP 
sent on point-point 
data link 


Retransmit SETUP; 
restart T303. If REL 
COMPLETE has 
been received, 
clear the call 


Clear network 
connection. Enter 
call abort state 


Mandatory 


T304 


20 s 

(provisional value) 


Overlap receiving 


SETUP ACK 
received. Sending 
of INFO restarts 
T304 


Send INFO; receive 
CALL PROC, ALERT 
or CONNECT 


Clear the call 


Timer is not 
restarted 


Mandatory only if 
5.2.4 implemented 


NOTE 1 : This default value assumes the use of default values at layer 2, i.e. [N200 + 1] times T200. Whether these values should be modified when layer 2 default 

values are modified by an automatic negotiation procedure is for further study. 
NOTE 2: The network may already have applied an internal alerting supervision timing function, e.g. incorporated within call control. If such a function is known to be 

operating on the call, then timer T301 is not used. 
NOTE 3: The value of timer T302 may vary beyond these limits, e.g. as a result of called party number analysis. 
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Table C.3: Q.931 - ISDN Timers in the user side- overview 



Timer 
number 


Default time-out 
value 


State of call 


Cause for start 


Normal stop 


At the first expiry 


At the second 
expiry 


Cross-reference 


T301 


Minimum 3 min. 


Call Delivered 


ALERT received 


CONNECT received 


Clear call 


Timer is not 
restarted 


Mandatory when 
Annex D is 
implemented (see 
note 3) 


T302 


15s 


Overlap receiving 


SETUP ACK sent 
Restart when INFO 
received 


INFO received with 
sending complete 
indication; or internal 
alerting; or internal 
connection; or a 
determination that 
sufficient information 
has been received 


Clear if call 
information 
determined to be 
incomplete; else 
send CALL PROC 


Timer is not 
restarted 


Mandatory only if 
5.2.4 is 
implemented 


T303 


4s 

(see note 1 ) 


Call Initiated 


SETUP sent 


ALERT (annex D), 
CONNECT 
(Annex D), SETUP 
ACK, CALL PROC or 
REL COMPLETE 
received 


Retransmit SETUP; 
restart T303. If REL 
COMPLETE was 
received, clear the 
call (Annex D) 


Clear internal 
connection. Send 
REL COMPLETE. 
Enter Null state 


Mandatory when 
annex D is 
implemented; 
otherwise optional 


T304 


30 s 


Overlap Sending 


INFO sent 
Restarted when 
INFO sent again 


CALL PROC, 
ALERT, CONNECT, 
DISC or prog. Ind. 1 
or 2 received 


DISC sent 


Timer is not 
restarted 


Optional 
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Annex D (normative): 
Overlap Sending 

D.1 multiple INVITE Overlap Dialling Procedures 
(Optional) 

D.1 .1 Actions at the originating VGW/AGCF 

D.1 .1 .1 Terminating overlap signalling at originating VGW/AGCF 

If overlap sending is used, the SETUP message contains either: 

a) no called number information; or 

b) incomplete called number information; or 

c) called number information which the network cannot determine to be complete. 

When the VGW/AGCF has received called number information element from the calling user in a SETUP message 
(possibly followed by INFORMATION messages), it shall send an INVITE request with all the available called number 
information in the Request line and the originating SDP (derived from the BC and optionally present HLC for the VGW 
- else as obtained from the originating AGW (and influenced by the BC and optionally present HLC)) - see 
table 5.1.1.1.4-2. 

The AGCF/VGW can contain a configurable digit map which is used to analyse the Called party information element 
contents received in a sequence of Called party number information elements. Among other purposes, this digit map can 
be used to: 

• Identify the required number of digits to be entered for a particular digit sequence. 

The procedures for digit maps are described within TS 183 043 [42], clause 7.3.1.3.1.1. Even in the absence of a digit 
map, it is appropriate for the AGCF/VGW to collect dialled digits. The AGCFVGW shall contain a configurable 
parameter indicating the minimum number of digits expected in the sequence of Called party number information 
elements before a Request-URI is constructed and an INVITE request sent. The minimum number could be zero. 

D.1 .1 .2 Sending of INVITE without determining the end of address signalling 

On receipt of such a SETUP message, the AGCF/VGW starts the ISDN timer T302, sends a SETUP ACKNOWLEDGE 
message to the user and enters the overlap sending state. 

If no number information is included the network will return dial tone, if required by the tone option. 

If the received BC in the SETUP message is coded with speech, 3,1 kHz audio, UDI/TA, it shall include 
progress indicator No. 8, in-band information or appropriate pattern is now available, in the SETUP 
ACKNOWLEDGE message. 

1) As a network option, the originating VGW/AGCF may send INVITE requests without determining the end of 
address signalling. If the originating VGW/AGCF sends an INVITE request before the end of address 
signalling is determined, the originating VGW/AGCF: 

uses the SIP precondition extension within the INVITE request; 

starts timer Tinfo if not running; and 

is prepared to process further incoming INFO as described below; 

is prepared to handle incoming SIP 404 or 484 error responses as detailed in clause D. 1 . 1 .3. 
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2) On receipt of a new DSS 1 INFO message, the originating VGW/AGCF shall: 
stop timer Tisdn3 (if it is running); 
send an INVITE request complying to the following: 

■ The INVITE request uses the SIP preconditions extension. 

■ The INVITE request includes all digits received so far for this call in the Request-URI. 

If subsequent address information in a DSSl INFO message is received after the SIP 404 or 484 error 
responses has been received, the INVITE request additionally includes the digits received. 

NOTE: The DSS 1 timer 302 is restarted with the receipt of a DSS 1 INFO message. 

At the receipt of a new DSSl INFO message, a SIP 18x provisional response, or a SIP 200 OK (INVITE), the 
originating VGW/AGCF shall stop Tisdn3. 

As a network option the Timer T-j^^^ can be used , in this case the following procedure apply starting with the first digit 
received by the AGCF/VGW : 

• Start timer T^^^^ with receiving the SETUP. 

• Collect all digits received within INFO messages. 

• At expiry of timer T^^f^ the initial INVITE is sent out as described under 1 . 

• If further digits are needed then the AGCFA^GW shall collect further digits until min length has been reached. 
As a network Option the first INVITE can be sent with the receipt of the SETUP message and the Tj^jj-^ is started. 

The Tjj^jp shall not be used if the INVITE has to be sent immediately because e.g. the hotline feature is provided to the 
originating user. 

D.1 .1 .3 Special handling of 404 Not Found and 484 Address Incomplete 
responses after sending of INVITE without determining the end of 
address signalling 

This Clause is only applicable when the network option of Sending of INVITE without determining the end of address 
signalling is being used (see clause D.1.1.2). 

On receipt of a 404 Not Found or 484 Address Incomplete response, the originating VGW/AGCF starts timer Tisdn3, if 
there are no other pending INVITE transactions for the corresponding call. 

At the receipt of fresh address information, or a SIP 18x provisional responses, or a SIP 200 OK (INVITE), the 
originating VGW/AGCF stops 302 and Tisdn3. 

The originating VGW/AGCF shall send a RELEASE message with Cause Value 28 towards the ISDN user if Tisdn3 
expires. 

Option a) Overlap with T^^^^ Timer. 
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AGCFA/GW 



SETUP 



^ 




SETUP ACK 






INFO 








INFO 








INFO 








INFO 








INFO 







CALL PROCEEDING 



L Info 



INVITE Cseq 1 



x-CSCF 



183 Session Progress Cseq 1 



Figure D.I. 1.3-1 : Overlap with Tj^fo Timer- no transaction is pending 
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AGCFA/GW 



SETUP 



SETUP ACK 



INFO 



INFO 



INFO 



INFO 



INFO 



INFO 



CALL PROCEEDING 



x-CSCF 



Info 



INVITE Cseq 1 



INVITE Cseq 2 



484 Cseq 1 



ACK 



183 Session Progress Cseq 2 



Figure D. 1.1 .3-2: Overlap with Tinfo Timer one transaction is pending 
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Option b) Overlap with Digit Map. 





SETUP 




AGCFA/GW 




x-CSCF 




















SETUP ACK 


















Digit map matched 








INFO 












INFO 












^^^^ 








INFO 








^,,,*ss=:^^ 


INVITE Cseq 1 






INVITE Cseq 2 






INFO 












484 Cseq 1 






ACK 






INVITE Cseq 3 






CALL PROCEEDING 








484 Cseq 2 






ACK 






. 183 Session Progress Cseq 3 

























Figure D.I. 1.3-3: Overlap with digit map 
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Option c) Overlap with Digit Map and T^^^^ Timer. 





SETUP 




AGCFA/GW 




x-CSCF 










Tinfc 














SETUP ACK 






> 


Digit map matched 
Stop Tinfo 








INFO 












^/^^ 








INFO 








INVITE Cseq 1 






INFO 












J 






INVITE Cseq 2 






INFO 














484 Cseq 1 








J 


^CK 






INVITE Cseq 3 






CALL PROCEEDING 








484 Cseq 2 










ACK 






183 Session Progress Cseq 3 



























Figure D. 1.1. 3-4: Overlap with digit map and Tinfo timer 
digit map matchied before Tj^f^ expiry 
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AGCFA/GW 



SETUP 



SETUP ACK 



INFO 



INFO 



INFO 



INFO 



INFO 



CALL PROCEEDING 



INVITE Cseq 2 



484 Cseq 1 



ACK 



183 Session Progress Cseq 2 



x-CSCF 




Figure D. 1.1. 3-5: Overlap with digit map and Tinfo timer 
digit map matched after Tj^fp expiry 



ETSI 



106 



ETSI TS 183 036 V3.3.1 (2010-04) 



Option d) 484 message with Min-length X parameter. 



AGCF/VGW 



SETUP 



SETUP ACK 



INFO 



INFO 



INFO 



INFO 



CALL PROCEEDING 



x-CSCF 



INVITE CSeq 1 



484 CSeq 1 Min-Lenght x Parameter 



ACK 



INVITE CSeq 2 



183 Session Progress CSeq 2 



Figure D. 1.1. 3-6: Overlap option with 484 message with IVIin-length x parameter 
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option c) 484 message without Min-length X parameter. 





AGCFA/GW 




x-CSCF 


SETUP 














INVITE 




SETUP ACK 


. 484 










ACK 




INFO 


INVITE 










484 






ACK 




INFO 


INVITE 










484 






ACK . 




INFO 


INVITE 








CALL PROCEEDING 


183 Session Progress 

















Figure D. 1.1 .3-7: 484 message without lUlin-lengtIi X parameter 

D.1 .2 Actions at the terminating VGW/AGCF 

See annex H for DDL For all other no further action is needed. 

D.2 In-Dialog IVIethod (Optional) 

D.2.1 Actions at the originating VGW/AGCF 

D.2.1 .1 Terminating overlap signalling at originating VGW/AGCF 

If overlap sending is used, the SETUP message contains either: 

a) no called number information; or 

b) incomplete called number information; or 

c) called number information which the network cannot determine to be complete. 
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When the VGW/AGCF has received called number information element from the calling user in a SETUP message 
(possibly followed by INFORMATION messages), it shall send an INVITE request with all the available called number 
information in the Request line and the originating SDP (derived from the BC and optionally present HLC for the VGW 
- else as obtained from the originating AGW (and influenced by the BC and optionally present HLC)) - see 

table 5.1.1.1.4-2. 

The AGCF/VGW can contain a configurable digit map which is used to analyse the Called party information element 
contents received in a sequence of Called party number information elements. Among other purposes, this digit map can 
be used to: 

• identify the required number of digits to be entered for a particular digit sequence. The procedures for digit 
maps are described within TS 183 043 [42], clause 7.3.1.3.1.1. 

Even in the absence of a digit map, it is appropriate for the AGCF/VGW to collect dialled digits. The AGCFVGW shall 
contain a configurable parameter indicating the minimum number of digits expected in the sequence of Called party 
number information elements before a Request-URI is constructed and an INVITE request sent. The minimum number 
could be zero. 

D.2.1 .2 Sending of INVITE without determining the end of address signalling 

On receipt of such a SETUP message, the AGCF/VGW starts the ISDN timer T3Q2, sends a SETUP ACKNOWLEDGE 
message to the user and enters the overlap sending state. 

• If no number information is included the network will return dial tone, if required by the tone option. 

• If the received BC in the SETUP message is coded with speech, 3,1 kHz audio, UDI/TA, it shall include 
progress indicator No. 8, in-band information or appropriate pattern is now available, in the SETUP 
ACKNOWLEDGE message. 

1) As a network option, the originating VGW/AGCF may send INVITE requests without determining the end of 
address signalling. If the originating VGW/AGCF sends an INVITE request before the end of address signalling 
is determined, the originating VGW/AGCF: 

use the SIP precondition extension within the INVITE request; 

be prepared to process INFO as described below; 

be prepared to handle incoming SIP 484 (Address Incomplete) responses; 

on receipt of 404 Not Found or 484 Address Incomplete start timer Tisdn3. 

2) On receipt of a new INFO from the DSS 1 side, the AGCF/VGW shall: 

if an early dialog has been established, send a SIP INFO request including the additional digits for this 
call; 

if an early dialog has not been established, wait for a final error response for the previous INVITE and 
send an INVITE request including all digits received so far for this call in the Request-URI. 

At the receipt of a new DSSl INFO message, a SIP 18x provisional response, or a SIP 200 OK (INVITE), the 
originating VGW/AGCF shall stop Tisdn3. 

As a network option the Timer Tj^j^^ can be used , in this case the following procedure apply starting with the first digit 
received by the AGCF/VGW: 

• start timer T^^^^^ with receiving the SETUP; 

• collect all digits received within INFO messages. 

• At expiry of timer Tjj^fp the initial INVITE is sent out as described under 1). 

If further digits are needed then the AGCF/VGW shall collect further digits until min length has been 
reached. 
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As a network Option the first INVITE can be sent with the receipt of the SETUP message and the Tjj^jg is started. 

The timer Tjj^j-^ shall not be used if the INVITE has to be sent immediately because e.g. the hotline feature is provided 
to the originating user. 

The originating VGW/AGCF shall send a RELEASE message with Cause Value 28 towards the ISDN user if Tisdn3 
expires. 

Option a) Overlap with T^^^^ Timer. 



AGCFA/GW 



SETUP 



SETUP ACK 



INFO 



INFO 



INFO 



INFO 



INFO 



CALL PROCEEDING 



T, 



Info 



INVITE Cseq 1 



x-CSCF 



183 Session Progress Cseq 1 



Figure D.2. 1.2-1 : Overlap with Tjnfo Timer- no transaction is pending 
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AGCFA/GW 



SETUP 



SETUP ACK 



INFO 



INFO 



INFO 



INFO 



INFO 



INFO 



CALL PROCEEDING 



x-CSCF 



Info 



INVITE Cseq 1 



183 Session Progress Cseq 1 



INFO Cseq 2 



200 Cseq 2 



183 Session Progress Cseq 1 



Figure D.2. 1.2-2: Overlap with Tinfo Timer no transaction is pending 
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Option b) Overlap with Digit Map. 





SETUP 




AGCFA/GW 




x-CSCF 




















SETUP ACK 


















Digit map matched 








INFO 












INFO 












^^^^ 








INFO 








^,^^£s=^^ 


INVITE Cseq 1 






183 Session Progress Cseq 1 








INFO Cseq 2 






INFO 












200 Cseq 2 








INFO Cseq 3 






CALL PROCEEDING 








200 Cseq 3 






^ 


183 Session Progress Cseq 1 

























Figure D.2. 1.2-3: Overlap with digit map 
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Option c) Overlap with Digit Map and T^^^^ Timer. 





SETUP 




AGCFA/GW 




x-CSCF 










Tinfc 














SETUP ACK 






> 


Digit map matched 
Stop Tinfo 








INFO 












^/^^ 








INFO 








INVIIbCseql 






INFO 












^ 


183 Session Progress Cseq 1 






5 




INFO Cseq 2 






INFO 












200 Cseq 2 










INFO Cseq 3 






CALL PROCEEDING 








200 Cseq 3 










183 Session Progress Cseq 1 



























Figure D.2. 1.2-4: Overlap with digit map and Tinfo timer 
digit map matchied before Tj^f^ expiry 
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AGCFA/GW 



SETUP 



SETUP ACK 



INFO 



INFO 



INFO 



INFO 



INFO 



CALL PROCEEDING 



x-CSCF 




183 Session Progress Cseq 1 



INFO Cseq 2 



200 Cseq 2 



183 Session Progress Cseq 1 



Figure D.2. 1.2-5: Overlap with digit map and Tinfo timer 
digit map matched after Tj^fp expiry 
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Option d) 484 message with Min-length X parameter. 





AGCFA/GW 




x-CSCF 


SETUP 














INVITE CSeq 1 




SETUP ACK 


484 CSeq 1 Min-Lenght x Parameter 










ACK 




INFO 


INVITE CSeq 2 




INFO 




INFO 




INFO 








CALL PROCEEDING 


1 83 Session Progress CSeq 2 

















Figure D.2. 1.2-6: Overlap option withi 484 message withi lUlin-lengthi x parameter 
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option c) 484 message without Min-length X parameter. 



AGCFA/GW 



SETUP 



SETUP ACK 



INFO 



INFO 



INFO 



CALL PROCEEDING 



INVITE 



ACK 



INVITE 



ACK 



INVITE 



ACK 



INVITE 



183 Session Progress 



x-CSCF 



484 



484 



484 



Figure D.2. 1.2-7: 484 message without IVIin-length X parameter 



D.2.2 Actions at the terminating VGW/AGCF 

See annex H for DDL For all other no further action is needed. 
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Annex E (normative): 
Direct Dialling in 

This annex describes the handling of Direct Dialling In. 



E.1 Multiple INVITES Method (Optional) 

E.1 .1 Actions at the incoming AGCF/VGW 
E.1 .1 .1 Receipt of Subsequent INVITE messages 

If the SETUP message has already been sent and the SETUP ACKNOWLEDGE message has been received, overlap 
receiving is used, an INFORMATION message will be sent upon receipt of each Subsequent INVITE. 

When the SETUP ACKNOWLEDGE message is received, the AGCF/VGW shall: stop timer T303; start timer T304; 
enter the Overlap receiving state; and send the remainder of the call information (if any) in one or more 
INFORMATION messages, starting timer T304 when each INFORMATION message is sent. 

At the expiration of timer T304 the network initiates call clearing with cause No. 28, invalid number format (address 
incomplete) to the calling user and cause No. 102, "recovery on timers expiry" to the called user. 



x-CSCF 



AGCFA/GW 



INVITE (79711) [Cseq1] 



INVITE (79711 1312)[Cseq2] 



484 [CSeq 1] 



ACK[CSeq1] 



INVITE (79711 1312 3) [Cseq 3] 



484 [CSeq 2] 



ACK [CSeq 2] 



183 [CSeq 3] 



SETUP (79711) 



SETUP ACK 



>-Tw304 

INFO (1312) 



)>~ Tw 304 
INFO (3) 



y Tw 304 



CALL PROCEEDING 



Figure E.1. 1.1-1 : Receipt of Subsequent INVITE messages 
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X-CSCF 



AGCFA/GW 



INVITE (79711) [Cseq1] 



INVITE (79711 1312)[Cseq2] 



484 [CSeq 1] 



ACK[CSeq1] 



INVITE (79711 1312 3) [Cseq 3] 



484 [CSeq 2] 



ACK [CSeq 2] 



183 [CSeq 3] 



SETUP (79711) 



SETUP ACK 



■^N 



^Tw304 

INFO (1312) 



^ Tw 304 
INFO (3) 



V Tw 304 



CALL PROCEEDING 



Figure E.I. 1.1-2: Receipt of Subsequent INVITE messages 

Receipt of subsequent INVITE messages 

This clause applies when overlap operation is supported across the AGCF/VGW. If the AGCF/VGW receives an 
INVITE with the same Call-ID and From tag as a previous INVITE which was associated with a DSSl call/bearer 
control instance currently existing on the DSSl side, then: 

a) If the number of digits in the Request-URI is a superset of the number of digits already accumulated for the 
call, the AGCF/VGW shall generate an INFO and pass it to outgoing DSSl procedures. The INFO shall 
contain in its Called party Number parameter only the additional digits received in this Request-URI compared 
with the digits already accumulated for the call. 

b) If the number of digits in the Request-URI is fewer than the number of digits already accumulated for the call, 
then the AGCF/VGW shall immediately send a 484 Address Incomplete response for this INVITE. In this case 
no INFO is sent to DSSl procedures. 



E.2 In-Dialog Method (Optional) 

E.2.1 Actions at the incoming AGCF/VGW 
E.2.1 .1 Receipt of Subsequent INVITE messages 

If the SETUP message has already been sent and the SETUP ACKNOWLEDGE message has been received, overlap 
receiving is used, an INFORMATION message will be sent upon receipt of each SIP INFO request carrying additional 
digits. 

When the SETUP ACKNOWLEDGE message is received, the AGCF/VGW shall: stop timer T303; start timer T304; 
enter the Overlap receiving state; and send the remainder of the call information (if any) in one or more 
INFORMATION messages, starting timer T304 when each INFORMATION message is sent. 
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At the expiration of timer T304 the network initiates call clearing with cause No. 28, invalid number format (address 
incomplete) to the calling user and cause No. 102, "recovery on timers expiry" to the called user. 



x-CSCF 



INVITE (79711) [Cseq1] 



183[CSeq 1] 



INFO(1312)[Cseq2] 



200 [CSeq 2] 



183[CSeq1] 



AGCFA/GW 



SETUP (79711) 



SETUP ACK 



INFO (1312) 



Tw304 



CALL PROCEEDING 



J 



Figure E.2.1 .1-1 : Receipt of SIP INFO request 



x-CSCF 




AGCF/VGW 






INV 


TE (79711) [Cseq 1] 










183 [CSeq 1] 




SETUP (79711) 








INFO(1312)[Cseq2] 


SETUP ACK 




Ltw304 




200 [CSeq 2] 




INFO (1312) 




^v * 




INFO (3) [Cseq 3] 




>- Tw 304 




200 fCSeq 3] 




INFO (3) 




1 






183 [CSeq 1] 


> Tw 304 

CALL PROCEEDING 
















J 



Figure E.2.1. 1-2: Receipt of SIP INFO requests 
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Receipt of SIP INFO requests 



This clause applies when overlap operation is supported across the AGCF/VGW. If the AGCF/VGW receives a SIP 
INFO request within an early dialog created by a previous INVITE, which was associated with a DSSl call/bearer 
control instance currently existing on the DSSl side, then the AGCFA'TW shall generate an INFO and pass it to 
outgoing DSSl procedures. The INFO shall contain in its Called party Number parameter only the additional digits, 
received in the SIP INFO request, compared with the digits already accumulated for the call. 
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Annex F (informative): 

Handling and interworking of DSS1 messages and 

Information Elements 

This annex describes the handHng and interworking of DSSl messages and Information Elements at the AGCF/VGW. 

Table F.I : DSSl messages 



DSSl Message 


Handling in SIP 


ALERTING 


Interworking with 180 Ringing 


CALL PROCEEDING 


Interworking with 183 Session Progress or local 
significance 


CONNECT 


Interworking with 200 OK INVITE 


CONNECT ACKNOWLEDGE 


local significance 


PROGRESS 


Interworking with 183 Session Progress or local 
significance 


SETUP 


Interworking with INVITE 


SETUP ACKNOWLEDGE 


local significance 


RESUME 


Interworking with INVITE or UPDATE containing the 
P-Service-Notification value "user-resumed" 


RESUME ACKNOWLEDGE 


local significance 


RESUME REJECT 




SUSPEND 


Interworking with INVITE or UPDATE containing the 
P-Service-Notification value "user-suspended" 


SUSPEND ACKNOWLEDGE 


local significance 


SUSPEND REJECT 




DISCONNECT 


Interworking with BYE, CANCEL or unsuccessful status 
responses 


RELEASE 


Interworking with BYE, CANCEL or unsuccessful status 
responses 


RELEASE COMPLETE 


Interworking with BYE, CANCEL or unsuccessful status 
responses or local significance 


INFORMATION 


Interworking with INVITE in case of overlap procedure 


NOTIFY 


Interworking with INVITE or UPDATE 


SEGMENT 


No interworking 


STATUS 


local significance 


STATUS ENQUIRY 


local significance 


USER INFORMATION 


No interworking 


CONGESTION CONTROL 


local significance 


RESTART 


local significance 


RESTART ACKNOWLEDGE 


local significance 


HOLD 


Interworking with INVITE or UPDATE. HOLD procedure 
based on TS 183 010 [10] 


HOLD ACKNOWLEDGE 


local significance 


HOLD REJECT 




RETRIEVE 


Interworking with INVITE or UPDATE. HOLD procedure 
based on TS 183 010 [10] 


RETRIEVE ACKNOWLEDGE 


Local significance 


RETRIEVE REJECT 




REGISTER 


Interworking with CCBS or CCNR 


FACILITY 


Operation of the configuration of services or user 
equipment 
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Table F.2: DSS1 Information Elements 



DSS1 Information Element 


Handling in SIP 


Protocol discriminator 


Local significance 


Call reference 


Local significance 


Message type 


Local significance 


Channel identification 


Local significance 


Bearer capability 


Interworking with INVITE, 18x, 200 OK 


High layer compatibility 


Interworking with INVITE 


Low layer compatibility 


Interworking with INVITE 


Progress indicator 


Interworking with INVITE, 18x, 200 OK 


Display 


Interworking with INVITE, 18x, 200 OK CANCEL, BYE 


Date/time 


Local handling 


Signal 




Sending complete 


Indication for end of dialling 


Keypad facility 


IVIaintenance of services 


Called party number 


Interworking with INVITE 


Calling party number 


Interworking with INVITE 


Calling party subaddress 


Interworking with INVITE 


Called party subaddress 


Interworking with INVITE 


Connected number 


Interworking with 200 OK/UPDATE 


Connected subaddress 


Interworking with 200 OK/UPDATE 


Redirecting number 


Interworking with INVITE 


Redirection number 


Interworking with 181, 180, 200 OK 


Cause 


Interworking with unsuccessful final response, BYE or 
CANCEL 


Notification indicator 


Interworking with INVITE, UPDATE, 18x, 200 OK 


Facility 


Maintenance of services 


Call identity 




Network-specific facilities 


No interworking 


Transit network selection 


No interworking 


Repeat indicator 




Call state 


local 


User-user 


Interworking with INVITE, 18x, 200 OK, BYE 


Information rate 




End-end transit delay 




Transit delay selection and indication 




Packet layer binary parameters 


(X25) 


Packet layer window size 


(X25) 


Packet size 


(X25) 


Closed user group 


No interworking 


Reverse charging indication 


No interworking 


IVIore data 




Restart indicator 


Local significance 


Locking Shift 




Non-locking Shift 
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Annex G (informative): 
Message flows 



G.1 Three party 



Basic call procedure and HOLD 



O-AGCFA/GW 



SETUP CR1 



ALERTING 



CONNECT 



HOLD 



SETUP CR2 



ALERTING 



CONNECT 



AS/MFRC 



INVITE (S1) 



ACK 



INVITE(S1,sendonly) 



ACK 



INVITE (S2) 



ACK 



UEB 



180 Ringing 



200 OK 



200 OK (recvonly) 



180 Ringing 



200 OK 



UEC 



Session 1 is set on HOLD 
according the HOLD 
simulation procedure 




Session 2 is 
established 



NOTE: Two sessions, one in hold one active. 

Figure G.1-1 : Initial position before starting the 3PTY service 
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O-AGCFA/GW 



FAC(CR1, beginSPTY inv) 



FAC(CR1, beginSPTY RR) 



AS/MFRC 



INVITE (S2, sendonly) 



ACK 



INVITE(S3,confAS) ^ 



200 OK 



ACK 



REFER(S1) 



202 Acepted 



REFER(S2) 



202 Acepted 



UEB 



200 OK(recvonly] 



Activate conference 



INVITE(S1, MFRP, sendrecv^ 



200 OK(sendrecv) 



ACK 



INVITE (S2, MFRP, sendrecv) 



ACK 



UEC 



200 OK(sendrecv) 



Session 2 

(internal) also on 

HOLD 



NOTE: The media streams shall be set on hold before 

Figure G.1-2: Invocation of three party session 
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0-AGCFA/GW 




AS/MFRC 




UEB 




UEC 


FAC(CR1 EndSPTY Inv) ^ 
























BYE(S3,confAS; ^ 










200 OK BYE 






INVIIb(S1,sendonly) 








200 OK(recvonly) 






ACK 








IN VI lb (S2, sendonly) 












200 OK(recvonly) 






ACK 




w 






INVITE (S2, sendrecv) 




w 






^ 




200 OK(sendrecv) 






ACK 








^FAC(CR1 EndSPTY RR) 








► 











Figure G.1-3: Release the three part conversation to have a 
private communication with the previous active user 
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0-AGCF/VGW 



FAC(CR1 End3PTY Inv) 



FAC(CR1 End3PTY RR) 



H0LD(CR2) 



RETREVE(CRl) 



AS/MFRC 



BYE(S3, conf AS) 



200 OK BYE 



INVITE(S1,sendonlv) 



ACK 



INVITE (S2, sendonly) 



ACK 



INVITE(S1,sendrecv) 



ACK 



UEB 



200 OK(recvonly) 



200 OK(sendrecv) 



UEC 



200 OK(recvonly) 



Figure G.1-4: Release the three part conversation to have a 
private communication with the previous held user 
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O-AGCFA/GW 




AS/MFRC 




UEB 




UEC 


DISCONNECT(CRl) ^ 
























BYE(S3, confAS; 


w 








200 OK BYE 






BYE(SI) 








200 OK BYE 






INVITE (S2,sendonlv) 












200 OK(recvonly) 






ACK 








^ RELEASE(CRl) 


INVITE (S2,sendrecv) 








RELEASE COMPLETE(CRI) 














200 OK(sendrecv) 






ACK 































Figure G.1-5: The served user releases the session with the previous held user 
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O-AGCFA/GW 




AS/MFRC 




UEB 




UEC 


DISC0NNECT(CR2) ^ 
























BYE(S3, confAS; 










200 OK BYE 






BYE(S2) 










200 OK BYE 






INVITE (SI, sendonlv) 












200 OK(recvonly) 






ACK 






^ RELEASE(CR2) 


INVITE (SI, sendrecv) 






RELEASE C0MPLETE(CR2) 












200 OK(sendrecv) 






ACK 























Figure G.1-6: The served user releases the session with the previous active user 
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O-AGCFA/GW 




AS/MFRC 




UEB 




UEC 






^ 






BYE(S1) 












200 OK BYE 








^DISCONNECT(CRl) 


BYE(S3,confAS) 












200 OK BYE 






INVITE (S2, sendonly) 










200 OK(recvonly) 




RELEASE(CRI) 


ACK 








INVITE (S2. sendrecv) 








RELEASE COMPLETE(CRI) 










^ 




200 OK(sendrecv) 






ACK 































Figure G.1-7: The previous held user disconnects the own session using basic call procedures 
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O-AGCFA/GW 




AS/MFRC 




UEB 




UEC 






^ 












BYE(S2) 






200 OK BYE 








^DISC0NNECT(CR2) 


BYE(S3,confAS) 
















200 OK BYE 






INVITE (S1,sendonly) 








200 OK(recvonly) 






ACK 






RELEASE(CR2) 


INVITE (S1,sendrecv) 


w 




RELEASE C0MPLETE(CR2) 




Rh 1 KIVE(CR1) 












200 OK(sendrecv) 






ACK 























Figure G.1-8: The previous active user disconnects the own session using basic call procedures 



G.2 Explicit Communication Transfer (ECT) 

Figures G.2.1 to G.2. 2 describe the message flow in case of interworking of the ECT supplementary service into the 
ECT simulation service. 
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O-AGCFA/GW 




AS 




UEB 




UEC 


SETUP (CR1) 




























ALERTING 


INVITE (CSq1) 












180Rinqinq 








200 OK INVITE 






CONNECT 




■< 


* ACK 














► 












Originating user invokes HOLD 






HOLD (CRD 






INVITE (CSq1,sendonly) 






















200 OK INVITE (recvonlv) 






* ACK 




















SETUP (CR2) 




Originating user establishes a communication with UE C 








INVITE (CSq2) 












ALERTING 










180Rinqinq 






^ 




200 OK INVITE 






CONNECT 






ACK 







































Figure G.2-1 : Basic procedure and remote user is set on IHOLD 
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0-AGCFA/GW 



X 



AS 

— I — 



UEB 



UEC 



Served user activates ECT 



FAC (CR1 EctExecute invoke) 



DISC0NNECT(CR1 EctExecute RR) 



RELEASE (CR2) 



RELEASE COMPLETE 



DISC0NNECT(CR2) 



RELEASE (CR2) 



RELEASE COMPLETE 



REFER (CSq1, Refer-To: 
UE C, Referred-By: UE A) 



202 Accepted 



NOTIFY (100 Trying) 



200 OK NOTIFY 



NOTIFY (200 OK) 



200 OK NOTIFY 



BYE(CSqla) 



200 OK BYE 



BYE (CSq2a) 



200 OK BYE 



INVITE (CSq1b, SDP=UE C) , 



200 OK INVITE 



INVITE (CSq2b, SDP=UE B) 



200 OK INVITE 



Figure G.2-2: Invocation of ECT 
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Annex H (informative): 
Use of progress indicators 



This annex describes the use of the different progress indicator values for non-ISDN and IMS terminals. The Progress 
Indicators for ISDN terminals in the IMS are only applicable for voice connection (speech and 3,1 kHz audio). 

Examples of use are given. 

• Progress indicator No. 1 - Indicates that interworking with a non-ISDN has occurred within the network or 
networks through which the call has traversed. 

• Progress indicator No. 2 - Indicates that the destination user is not ISDN. 

• Progress indicator No. 3 - Indicates that the origination user is not ISDN. 

• The ISDN access indicator (see note) - "originating access ISDN" is transported in the IMS as PSTN XML 
Progresslndicator No. 6. 

• The ISDN access indicator (see note) - "Terminating access ISDN" is transported in the IMS as PSTN XML 
Progresslndicator No. 7 

NOTE: The "ISDN access indicator" is defined in the ITU-T Recommendation Q.763 [i.2] in the BCI and FCI 
and indicates the access type. The access indicator can be not directly mapped to the ISDN progress 
indicator and is not defined in EN 300 403-1 [29]. The ISDN access indicator can be created only from 
the network e.g. VGW, AGCF, SIP/ISUP MGCP, not from the UE and shall prevent the sending of a 
progress indicator indicating a non-ISDN connection. 

The use of progress indicators Nos. 1, 2 and 3 is exemplified in the following. 

Several interworking situations are identified in figure H-1: 

a) interworking with another network; 

b) interworking with a non-ISDN user connected to ISDN; 

c) interworking with non-ISDN equipment within the calling or called user's premises; 

d) interworking with another network behind the T reference point; 

e) interworking with an IMS network behind the S/T reference point (simulated service); 

f) interworking with an IMS network behind the S/T reference point (simulated /emulated service in the AGCF); 

g) interworking with an IMS network behind the Gm reference point; 

h) interworking with non-ISDN equipment within the calling or called user's premises which is connected to an 
IMS network; 

i) interworking with another network behind the T reference point which is connected to an IMS network. 
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As regards calls from A (ISDN access in an ISDN network) the following applies: 



Case 


Originating Terminal A receives 
PI 


Originating side 

or 
SIP/ ISUP IMGCF 
(PI from the BCI) 

«■ PI sent 


Terminating side 
«- PSTN XML 
Progresslndicat 
or sent 


Term. Terminal 
sent 


a 


Pl#1 




Pl#1 




b 


PI #2 




PI #2 




c 


PI #2 
location sub-field = private network 






PI #2 


d 


Pl#1 
location sub-field = private network 






Pl#1 


IMS 


e 






PI #7 




f 






PI #7 




g 


Pl#1 


Pl#1 






h 


PI #2 


PI #2 


PI #7 


Pl#2 


i 


Pl#1 


Pl#1 


PI #7 


Pl#1 



As regards calls towards A the following applies: 



Case 


Orig Terminal 
PI sent 


Originating 
VGW/AGCF 
PSTN XML 
Progresslndicator 
sent 


Originating side 

or 
SIP/ ISUP MGCF 

PI 
sent in the FCI 


Terminating 
lnterworl<ing 

function 
(AGCF/VGW) 


Dest. Terminal A 
receives PI 


a 






Pl#1 




Pl#1 


b 






Pl#3 




PI #3 


c 


Pl#3 








PI #3 
location sub-field 
= private 
network 


d 


Pl#1 








Pl#1 
location sub-field 
= private 
network 


IMS 1 


e 




PI #6 








f 




PI #6 








g 




PI #6 








h 


Pl#3 


PI #6 






PI #3 


i 


Pl#1 


PI #6 






Pl#1 



As regards calls from C or D (ISDN access in the IMS) the following applies: 



Case 


Originating C or D Terminal 
receives PI 


0-AGCF/VGW 
«■ PI sent in 18x 


«■ PI sent 

Destination 

MGCF 


Term. Terminal 
sent 


a 


Pl#1 








b 


Pl#2 




PI #2 




c 


Pl#2 






PI #2 


d 


Pl#1 






Pl#1 
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Case 


Originating C or D Terminal 
receives PI 


0-AGCF/VGW 
4- PI sent In 18x 


«■ PSTN XML 
Progresslndicator 
sent 
Destination 
MGCF 


Term. Terminal 
sent 


e 






PI #7 




f 






PI #7 




g 


Pl#1 


Pl#1 






h 


PI #2 






Pl#2 


i 


Pl#1 






Pl#1 



As regards calls towards C or D (non-ISDN access in an ISDN network) the following applies: 



Case 


Orig Terminal 
PI sent 


Originating side 

or 
SIP/ ISUP IWF 

PI 
sent in the FCI 


Terminating 
Interworking 

function 
(AGCF/VGW) 


Dest. Terminal 
Cor D 
receives PI 


a 




Pl#1 


Pl#1 


Pl#1 


b 




Pl#3 


Pl#1 


PI #1 and PI #3 


c 


Pl#3 




Pl#1 


PI #1 and PI #3 


d 


Pl#1 




Pl#1 


Pl#1 


e 






Pl#1 


Pl#1 


f 






Pl#1 


Pl#1 


g 






Pl#1 


Pl#1 


h 


Pl#3 




Pl#1 


PI#1andPI#3 


i 


Pl#1 




Pl#1 


Pl#1 
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ISDN 
Tel. 



S/T 




non-ISDN user 



/r^ ( Non 
KJ V ISDN 



Figure: H.I 
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